Live data from Hacker News

Show HN: Kryptonite – a new home for your SSH private key

krypt.co

111–120 of 227 posts

Re: Show HN: Kryptonite – a new home for your SSH private key

#111
post #66

Earlier quoted context omitted.

The agent process is tricky to set up and persnickety, especially if you use the token for anything else besides SSH. At one point, before I tableflipped and switched back to software keys, I had to switch agent processes any time I used my Y4 to sign into a VPN. The theater is that you're protecting a key but not the account the key protects . Yes, you'll never lose the actual RSA key bits to an attacker. But that'l…

>Yes, you'll never lose the actual RSA key bits to an attacker. But that'll be cold comfort after an attacker uses a hijacked SSH process to compromise every account you log into. But if you enable (and require) the touch feature, it'll be pretty obvious if someone's trying to use your agent to authenticate somewhere else, no? I'd certainly notice if I had to press the button twice while I'm logging into a machine th…

They don't have to use your agent to authenticate again. They just feed commands to your SSH client binary that it then sends over the wire in your existing SSH session-context, with the SSH pty temporarily set to not echo input and discard output (or return it over the network to the attacker, but not render it in the local PTY character-buffer.) A hijacked SSH binary can even detect an elevation-requiring command you provided in the terminal and wrap it in a "sudo -c" along with a payload, such that the whole thing happens as one elevated "transaction", only hitting your agent once.

Happily, this won't work if you only ever use SSH with a non-shell command, e.g. as a fancy encrypted netcat(1).

Re: Show HN: Kryptonite – a new home for your SSH private key

#112
post #66

Earlier quoted context omitted.

What specifically do you consider a gigantic pain in the ass about using SSH keys on a Yubikey? Also, how is keeping the private key ensconced in a (presumably) secure HSM a 'bit of security theatre'? Genuinely interested, here.

The agent process is tricky to set up and persnickety, especially if you use the token for anything else besides SSH. At one point, before I tableflipped and switched back to software keys, I had to switch agent processes any time I used my Y4 to sign into a VPN. The theater is that you're protecting a key but not the account the key protects . Yes, you'll never lose the actual RSA key bits to an attacker. But that'l…

FWIW, I never had that issue with my NEO on OSX/macOS. I was using my NEO for git signing, SSH, as well as U2F.

Re: Show HN: Kryptonite – a new home for your SSH private key

#113
post #92

Earlier quoted context omitted.

What's really happening is that fans of phone security want to say "iPhone" rather than "phone", but when they do that on HN, Linux-on-the-desktop Android supporters come out of the woodwork to yell at them, and it's a winnable argument on a thread that is only about whether iPhones are more secure than Android phones, but not on broader threads where it's just an enormous distraction. As you can see from this thread…

Since Kryptonite is available for Android phones, it's a point at least worth highlighting. One might think that anyone savvy enough to want an app to manage his ssh private keys would also think about his phone's security. In practice, from my observation, a lot of people who have to use ssh keys don't really understand them and would not think twice about loading an app like this onto their Android phones, alongsid…

Edit: misread the message. Removed.

Re: Show HN: Kryptonite – a new home for your SSH private key

#114

Earlier quoted context omitted.

Since Kryptonite is available for Android phones, it's a point at least worth highlighting. One might think that anyone savvy enough to want an app to manage his ssh private keys would also think about his phone's security. In practice, from my observation, a lot of people who have to use ssh keys don't really understand them and would not think twice about loading an app like this onto their Android phones, alongsid…

Edit: misread the message. Removed.

[deleted]

Re: Show HN: Kryptonite – a new home for your SSH private key

#115
post #103
post #44

Clever that it uses the client instead of the server! I've dabbled with phone-based authentication via a server-side PAM module before, but you generally don't have full control over the servers you SSH into. Although the question remains: is this more secure than just storing your key on your computer? If you're assuming your machine to be compromised, then as soon as you login to another server you've basically giv…

You've hit the nail on the head. If your computer's ssh binary can be compromised so can krd. If the main objective is to prevent other apps in user space from reading unlocked private keys, why not just ssh/sudo into a secondary account where the default shell is set to an ssh client?

The point is, even when krd is compromised, the malicious party cannot gain access to your private key. They key is only stored on your phone and you have to physically confirm the login from your phone.

Re: Show HN: Kryptonite – a new home for your SSH private key

#116
post #67

Earlier quoted context omitted.

y4 is one more thing to worry about. to lose. to have stolen. to drop in the toilet. etc. i think part of the "theatre" is the whole convenience for safety thing. a few years ago it was gospel to change your passwords all the time. then some data started to point to this actually might be bad because it forced users into to using easy to remember things like sequences, or write them down (often in something like note…

> y4 is one more thing to worry about. to lose. to have stolen. to drop in the toilet. etc. How is this different from your phone?

Presumably most of the people in this thread already have a smartphone. So it isn't really one _more_ thing.

Re: Show HN: Kryptonite – a new home for your SSH private key

#117
post #88

Earlier quoted context omitted.

>>> The phone's kernel, in addition to being more important attack surface than the Linux kernel (because of the jailbreak market, among other things), is auto-updated. Most android phones are not updatable at all since manufacturers don't publish any update. That, alone, should be enough to put phones among the most vulnerable devices on the planet.

It puts those Android phones among the more vulnerable devices. Don't use those Android phones. I recommend iPhones to anyone concerned about security, but you can substitute the Google phone of your choice; I don't want the argument today.

What's cheaper - an iOS phone, or an Android phone + a Yubikey?

Re: Show HN: Kryptonite – a new home for your SSH private key

#118
post #7

Hi, that looks good! I'll probably try it out soon. One suggestion regarding PCI DSS: you should probably make a page/whitepaper that outlines the compliance story of Kryptonite. ScaleFT has a great one: https://www.scaleft.com/use-cases/pci-dss/ . By the way, have you checked that you do not need to be compliant yourself?

Theoretically this solution could be classified as a mutlti-factor authentication, which covers PCI DSS Requirement 8.2. See also https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authe...

Beyond that, there isn't much else this does regarding PCI. SSH does the rest.

Re: Show HN: Kryptonite – a new home for your SSH private key

#119
post #54
post #47

I haven't reviewed the implementation, but this is a really good idea. I want one.

I will likely end up using this in personal capacity, and would also appreciate if the UX of using Google Authenticator were more similar to this, rather than requiring me to screenscrape my phone with my eyeball and then type information into another device (or, more painfully, another window on the same phone). The easiest way to do that probably results in a callback to Big Daddy G every time I access anything sen…

Although I'm a bit skeptical of its security, you might want to check out Authy.

Re: Show HN: Kryptonite – a new home for your SSH private key

#120
post #46
post #33

It sounds very hipster and all, but how is a phone more trustworthy than a Linux PC? Cool, we don't need to trust a PC, now we have to trust a phone and pretend that malware for smartphones don't exist at all. Hardware USB token looks much better as its attack surface is so much smaller than iOS/Android.

* Every application on the phone is sandboxed. * The disk is encrypted by default, and the OS is aggressive about keeping it encrypted ; a booted-up computer is almost always decrypted. * The language runtimes on the phone are hardened. * The phone's kernel, in addition to being more important attack surface than the Linux kernel (because of the jailbreak market, among other things), is auto-updated. * The phone's us…

>> Every application on the phone is sandboxed

Note that you are trusting this app with your private key. While other apps are sandboxed away from having access, all it takes is one update to the app to sneak away your private key to any remote server. You have to trust the publisher of this app, including their entire chain of source code repository management and app build/release process. It takes a single instance of a malicious person inserting code that steals all users' private keys (disgruntled employee at this company, or social engineering attack to gain access to commit to their GitHub, etc.).

It's the same reason I am horrified that anyone trusts password managers from for-profit companies. Those companies have unfiltered potential access to your entire online identity, including critical logins like your bank and government services. The app is sandboxed, and the company promises that your (unencrypted) credentials never leave the local device. But it is impossible for them to offer an absolute guarantee that their app will never be the target of an attacker slipping in code that steals information.

In this particular case, you're giving a single app access to potentially expose your key to theft. Less risky than storing your key in the default ~/.ssh/id_rsa, where any app running on your desktop machine has access to read it. Also likely to be less devastating of a loss compared to the compromise of the contents of a password manager.

Post reply on HN