Hacker News Reader

Comment by dantillberg | Hacker News Reader

This is a neat idea, and I like innovative sound to it.

But what happens if the key is compromised during this single use? Isn't that just as problematic from a security perspective?

I'm guessing by "untrusted system" that we're talking about an SSH host for which you do not already have and verify the SSH host fingerprint (see side note below). And so, for example, you try to connect to that host, but instead your request is MITMed and the attacker has control of your session with that remote host.

Or put another way: what attack vectors are prevented/mitigated by disabling the key on use? (and this is separate from the very inconvenient aspect regarding: how do I connect back to that host after my one session is over?)

(side note: I believe that if you don't verify host keys, then SSH is completely, 100% useless against MITM/proxy attacks, whether you allow the key to be used 1 or infinite times. Please correct me if I'm wrong on that.)

View on HN

(disclaimer, i'm the co-founder of ScaleFT, a startup building products in this space: https://www.scaleft.com )

I believe that "ephemeral" or "dynamic" credentials is a concept that is just starting to emerge.

This particular implementation, I don't see what threats it is really stopping.

One question we lead with at ScaleFT is, "How Old should an SSH Key be?". It leads many to admit they have had the same key, across multiple companies, across multiple devices. The threats against that kind of private key are massive, everything from an old corporate backup at a company you don't even work at anymore, to an APT capturing it 3 weeks ago.

Basically using an SSH key, doesn't prove much, except that at any point in time, you had the associated private key. This is a pretty broad attestation of identity -- so generating a key for every use -- and then building in additional attestations of identity (eg, two factor) for the use of that key, is something I think we will see more of in the future.

Can you explain on how it (new key for every use) could work? If you already have a system (e.g. similar to the current CA system) to tell the remote server to allow a newly generated key in, what purpose does the key serve here at all?

Also - the encrypted private key is already two-factor authentication - you have the key and you know the encryption password for the key. Is this fact usually ignored by everyone because paswordless keys are that common?

As for the "age" of a key, I totally agree here - using the same key forever and on multiple devices (especially in multiple companies) is asking for trouble. I'm not completely sure what the best practice is, but the user@hostname appended to the end of the public key sort of suggests you are supposed to have a separate key on each host - that's what I do.

Co-founder of ScaleFT here.

With a CA system you still need a key of some sort just due to how it works, but you're right that generating a new one every time isn't as critical because you are authorized by the tuple of (key, certificate). But certificates aren't intended to be treated as secrets, so re-generating the key frequently still adds a lot of value.

Passphrases are a good start towards protecting a key. As an individual, if you use a passphrase, secure your laptop or workstation, and rotate your key frequently (remove the public key everywhere it is trusted) you'll probably be OK. AnthonyMouse is right about the advantages of checking a password server-side though.

Another neat advantage of moving identity verification online is that you can adopt more interesting auth mechanisms and blocking heuristics. Think of all the things that Google et al do to secure logins.

The real take-away here though is that while an individual can do a pretty reasonable job of securing an SSH key if they practice strong discipline[1], the risk for a team of individuals grows with its size. All it takes is for one team member to have their laptop compromised, and the game is over. SSH keys just don't provide a reasonable way to manage, or even assess this risk.

[1] around securing their laptop, using a passphrase, ideally not using ssh-agent, definitely never forwarding ssh-agent, rotating frequently, etc

Did some reading on ScaleFT website.

To be honest - I'm a bit conservative especially when dealing with security. I don't believe you should "put your ssh keys in the cloud" to make them more secure. So I'm somewhat biassed.

Anyway - considering the single developer's laptop, you can't improve much on ssh keys. You might be able to add 2FA using some token. You might also improve the key management software to notify and help rotate keys. "Cloud" based solutions won't add security either - the api keys used to access the service can be compromised as easily.

If we are taking about a company/enterprise, then I'm all for centralized authentication/authorization. But in this case there are a couple of decades old solutions - Kerberos. It won't give you expiring SSH keys, but week give you expiring tickets.

> Can you explain on how it (new key for every use) could work? If you already have a system (e.g. similar to the current CA system) to tell the remote server to allow a newly generated key in, what purpose does the key serve here at all?

It protects against old key compromise. Sometimes the attacker will compromise a key from a week-old backup or because someone forgot to wipe the disk when they replaced a PC. If the key is changed on every use or on a short interval then it will be unusable by the time the attacker learns it.

Of course, that also means a backup of the key will be unusable to the actual user.

> Also - the encrypted private key is already two-factor authentication - you have the key and you know the encryption password for the key. Is this fact usually ignored by everyone because paswordless keys are that common?

Key files encrypted with passwords are weak because an attacker who compromises the key file can then crack the password offline. By contrast, when the password is verified by the remote server, the attacker has to guess passwords online, which is much slower and allows the server to block or rate limit the attacker after too many bad passwords.

> Key files encrypted with passwords are weak because an attacker who compromises the key file can then crack the password offline.

If like to see them try with a 18 character long password.

Btw: is there a way to convert a private key to such a format which looks absolutely random (so the attacker can't tell if the decryption worked until they try to use the key)? Though IIRC three are some prime numbers there... Might not work.

Well considering how obscure the software is that implements it now, I can understand why you'd assume that.

However according to the Fox Technologies Wikipedia Page, BoKS aka KEON includes support for "...SSH protocols: SSH keys generated by FoxT ServerControl, or to re-use existing SSH distributed keys.", and they've had that technology for years.

Trust me - I'm not denigrating what you guys are doing and in fact I look forward to concepts like this found in BoKS making it into wider circulation. Just saying there may be a little prior art, as it were.

I think the "untrusted system" in question is the system you're logging on from, because that's the only place where the private key could be compromised. I guess the idea is something like, you have a desperate need to log in to a server but the only computer you have physical access to is a machine you don't control (in an internet cafe, say). So you keep your one-time SSH key on a flash drive, use that key on the untrusted machine to log into your server, and you don't have to worry about the untrusted machine keeping a copy of your key (because that key is no longer valid). On the other hand, you do still have to worry about the untrusted machine injecting malicious commands into your session (including, possibly, malicious commands which would allow the attacker to log in to the server as you again in the future).

One application I can think of for this is to have it as part of your "self-destruct" script to move files to a safe location and not possess the knowledge to access them until either you are safe or at a planned later date.

Reply on news.ycombinator.com