Not sure why this comment was downvoted. Just highlights the inherit security vulnerability of trusting such sensitive data (Private SSH Keys) with a system that doesn't have a proper security audit.
Simply open sourcing your code is not enough, especially with files like this still lying around in the code base. Just shows a level of professionalism that is lacking, that needs to be taken seriously for security products.
I am intrigued by the app, but they have some glaring holes I don't think they have addressed.
I think that file is just clearly unnecessary and it just shows sloppy project management to leave a file like that in a production (open source) codebase.
It's 1.2M for an app that doesn't meaningfully increase security. Let's suppose this thing gets somewhat popular. Now malware will detect the presence of this app, wait until a legitimate request gets initiated, and piggy back off that. You approve the request, the malware logs into your servers/repos, does whatever evil thing it needs to do, let the original app do its thing, and you're none the wiser.
Your attack vector is correct, but Kryptonite is still a step up from existing solutions since you know exactly when your key is used and what host is being logged in to (the app does known host pining as well).
YubiKeys don't have a UI to show you what you're approving plus suffer the same problem you described. Most developers store keys as files on their machine which can be easily stolen (even if they're encrypted on disk) and used to authenticate to as many servers as the adversary likes without you even knowing.
But YubiKeys are built on a hardened hardware security module instead of a general purpose phone operating system with full network connectivity and a huge attack surface.
Having a UI does not increase security in a meaningful way. The attacker is just going to wait until the victim connects to an interesting target server and then hijack that connection. The ControlMaster feature makes that trivially easy, but it's not hard to do real injection [1].
If the workstation is compromised, it's over.
At that point, all you can do is to prevent an attacker from copying the key or using it without user interaction. A YubiKey does both - you can optionally set it to a mode where you have to approve each signature.
With a bank transaction, the whole transaction is part of the approval process and can be verified out-of-band. With a SSH login, this is not possible since you're still going to trust the workstation as soon as the session is established.
I'm not saying this project is useless - IF your phone is actually more secure than your workstation - which may or may not be the case - AND you've been previously been storing your keys on your workstation, then it's definitely a step up. But really, at that point, just buy a YubiKey (and properly secure your workstation!).
Otherwise, you now have TWO single points of failure instead of one. If either your phone or your laptop is compromised, it's over.
If you want login approvals that show the server name, do it as a second factor and use something like Duo Security with push approvals. This actually increases your security - instead of having, an attacker would now have to compromise both of your devices.
The iPhone has a secure enclave that does elliptic curve key generation and signing[0]. I'd be surprised if they do not implement that soon; it's not terribly difficult[1].
You'd have to elaborate a bit on your theoretical attack here.
1. A request and its signed response can only be used for a specific login attempt by SSH design.
2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods.
3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user.
4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval.
If you want to trick the user to accept your request by firing it simultaneously with a legitimate one, you first have to steal pairing data from the machine the user is logging in from. Then, you'd either have to auth against the very same host as the user, or have the request say that the host is unknown (sticks out, seeing that the legitimate request is also there). There would also be two requests in a row, which might warn the user.
The other attack vector I can think of would be trying to accept a random request done by an attacker, either by tricking the user (clickjacking-style) or by using an exploit on the device.
A yubikey-like device with a screen displaying request information and a hardware approval method would be better than an arbitrary android device, but I would argue that the model presented by this piece of software isn't as bad as you make it sound.
> s yet, there are no known exploitable vulnerabilities in SSH2, though information leaked by Edward Snowden in 2013 suggests the National Security Agency may be able to decrypt some SSH traffic. http://searchsecurity.techtarget.com/definition/Secure-Shell
I really don't understand how people continue to state wrong information about ssh. Is it because of Heart Bleed? SSH is 22 years old and is still a solid tool. The only bad thing about ssh is key management which this company is addressing.
>1. A request and its signed response can only be used for a specific login attempt by SSH design.
>3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user.
>4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval.
So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.
>2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods.
Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.
> Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.
Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one.
> So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.
I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour").
If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem.
If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on.
Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.).
With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).
>2. The app, through some nasty hacks, receive the host auth blob from the server to verify.
What do you mean here? is the host auth blob coming from the third party service you are trying to auth to (e.g. Github), or from the initial client making the auth request (e.g. "Request from Macbook")?
It puts a little nc-like tool as ProxyCommand, parsing all traffic for host-auth like packets coming from the target machine. It then sends it to the app, so that it can verify the signature of the remote host before prompting you for approval.
That's a fair assessment, I would imagine by the time the malware has made it on a host, none of what you mentioned is materially relevant given that malware has made its way on the host.
The iPhone has a secure enclave that does elliptic curve key generation and signing[0] (the key obviously cannot be exported). I'd be surprised if they do not implement that soon; it's not terribly difficult[1].
Why on earth would I want my ssh keys on a device that is almost always connected to the internet if security is a major concern? A Yubikey (hardware based key) is by far the best solution.
Your desktop is also always connected to the internet (unless you're have very very high security requirements). And your desktop probably runs way more untrusted code with less sandboxing. Of course a hardware key is more secure, but this seems like a meaningful improvement over normal key files.
Any Windows support? YubiKey's advantage (Aswell as the fact that it's designed for keystorage, and malware can now just target Android and can automatically approve it themselves) is that it works crossplatform; I can use a YubiKey (when I can afford one) with PuTTY - there seems to be no way to do this.
We currently support Bash on Ubuntu on Windows, but PuTTY/Cygwin support is further off.
A code execution exploit on your Android phone would result in being able to approve automatically, but without Kryptonite, a trojan in _any_ of the apps on your computer could steal your SSH key and use it unhindered, like what recently happened to Handbrake [https://threatpost.com/handbrake-for-mac-compromised-with-pr...]
I've been using Kryptonite a little bit and generally I'd say it's been a pretty pleasant experience. While I personally haven't spent much time weighing the pros and cons from a security perspective (and I'm not a security expert, so in all likelihood I'm not in a position to give a fair evaluation of it), from an overall user experience perspective these guys have done a really solid job.
If I have any gripe it's that, when using with Git, Visual Studio Code's Git autofetch feature winds up causing Kryptonite to issue a push notification to my phone every couple of minutes after first authorizing for three hours, with no way to granularly suppress notifications. That's really kind of the point of Kryptonite, obviously, but it's possible there's a better solution for this on Kryptonite's end that wouldn't require any contortions from users.
How does this work if you lose or break your phone?
I know several people who use 2FA apps on their phones to log onto services and whose phones broke and they couldn't log on. While there is usually some way to recover your logon I'd argue that for most people and uses the chances of losing/breaking/replacing their phone and having to go through a painful recovery process outweigh the security advantages.
> What happens if I lose my phone?
> First make sure you remove the old SSH public key from any of your accounts. Once you have Kryptonite installed on your new phone, add the new public key to the accounts you were using SSH with before.
So basically you'd need to have an alternative method of authentication to be able to add the new public key (and remove the lost one).
Your phone has a secondary processor with access to main memory. That secondary processor runs often incredibly jank code, and that code can often be changed at will by your mobile carrier.
Your laptop/desktop are not secure either. That said, cell phones today have everything... every little bit of everyones life embedded on them. The are on all the time. They are not patched as often as desktop OS's. They are juicy delicious targets and great listening / tracking devices. Laptops can be used this way, but nowhere near the same target value.
I forgot to mention, all cellphones come bundled with vendor installed spyware. CarrierIQ is one such example, now owned by AT&T, but there are many of them. They will tell you it is only enabled when your device is in debug mode, but your device dials home all the time and a single http header can enable debug for a period of time.
42 comments
[ 2.8 ms ] story [ 49.6 ms ] threadWhat would they even do with this money?
Cannot wait to trust these guys with my ssh key!
/s
Simply open sourcing your code is not enough, especially with files like this still lying around in the code base. Just shows a level of professionalism that is lacking, that needs to be taken seriously for security products.
I am intrigued by the app, but they have some glaring holes I don't think they have addressed.
YubiKeys don't have a UI to show you what you're approving plus suffer the same problem you described. Most developers store keys as files on their machine which can be easily stolen (even if they're encrypted on disk) and used to authenticate to as many servers as the adversary likes without you even knowing.
Having a UI does not increase security in a meaningful way. The attacker is just going to wait until the victim connects to an interesting target server and then hijack that connection. The ControlMaster feature makes that trivially easy, but it's not hard to do real injection [1].
If the workstation is compromised, it's over.
At that point, all you can do is to prevent an attacker from copying the key or using it without user interaction. A YubiKey does both - you can optionally set it to a mode where you have to approve each signature.
With a bank transaction, the whole transaction is part of the approval process and can be verified out-of-band. With a SSH login, this is not possible since you're still going to trust the workstation as soon as the session is established.
I'm not saying this project is useless - IF your phone is actually more secure than your workstation - which may or may not be the case - AND you've been previously been storing your keys on your workstation, then it's definitely a step up. But really, at that point, just buy a YubiKey (and properly secure your workstation!).
Otherwise, you now have TWO single points of failure instead of one. If either your phone or your laptop is compromised, it's over.
If you want login approvals that show the server name, do it as a second factor and use something like Duo Security with push approvals. This actually increases your security - instead of having, an attacker would now have to compromise both of your devices.
[1]: https://github.com/seastorm/PuttyRider
[0] https://twitter.com/iangcarroll/status/830878517730623492
[1] https://developer.apple.com/documentation/security/1644033-s...
1. A request and its signed response can only be used for a specific login attempt by SSH design.
2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods.
3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user.
4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval.
If you want to trick the user to accept your request by firing it simultaneously with a legitimate one, you first have to steal pairing data from the machine the user is logging in from. Then, you'd either have to auth against the very same host as the user, or have the request say that the host is unknown (sticks out, seeing that the legitimate request is also there). There would also be two requests in a row, which might warn the user.
The other attack vector I can think of would be trying to accept a random request done by an attacker, either by tricking the user (clickjacking-style) or by using an exploit on the device.
A yubikey-like device with a screen displaying request information and a hardware approval method would be better than an arbitrary android device, but I would argue that the model presented by this piece of software isn't as bad as you make it sound.
I really don't understand how people continue to state wrong information about ssh. Is it because of Heart Bleed? SSH is 22 years old and is still a solid tool. The only bad thing about ssh is key management which this company is addressing.
What would you replace it with?
>3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user.
>4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval.
So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.
>2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods.
Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.
Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one.
> So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host.
I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour").
If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem.
If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on.
Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.).
With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).
What do you mean here? is the host auth blob coming from the third party service you are trying to auth to (e.g. Github), or from the initial client making the auth request (e.g. "Request from Macbook")?
I carry my KeePassX DB on my phone and know it is slightly safer than typical cloud providers because it isn't actively being targeted.
That said, I would try this out.
Maybe if modern phones have special hardware features where key material can be stored, so that it can't be duplicated.
The iPhone has a secure enclave that does elliptic curve key generation and signing[0] (the key obviously cannot be exported). I'd be surprised if they do not implement that soon; it's not terribly difficult[1].
[0] https://twitter.com/iangcarroll/status/830878517730623492
[1] https://developer.apple.com/documentation/security/1644033-s...
A code execution exploit on your Android phone would result in being able to approve automatically, but without Kryptonite, a trojan in _any_ of the apps on your computer could steal your SSH key and use it unhindered, like what recently happened to Handbrake [https://threatpost.com/handbrake-for-mac-compromised-with-pr...]
If I have any gripe it's that, when using with Git, Visual Studio Code's Git autofetch feature winds up causing Kryptonite to issue a push notification to my phone every couple of minutes after first authorizing for three hours, with no way to granularly suppress notifications. That's really kind of the point of Kryptonite, obviously, but it's possible there's a better solution for this on Kryptonite's end that wouldn't require any contortions from users.
> What happens if I lose my phone? > First make sure you remove the old SSH public key from any of your accounts. Once you have Kryptonite installed on your new phone, add the new public key to the accounts you were using SSH with before.
So basically you'd need to have an alternative method of authentication to be able to add the new public key (and remove the lost one).