4 ms·

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

by pquerna 11y ago

(disclaimer, i'm the co-founder of ScaleFT, a startup building products in this space: https://www.scaleft.com 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.

skarap 11y ago
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.
- AnthonyMouse 11y ago
  > 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.
  - skarap 11y ago
    > 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.
- russell_h 11y ago
  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
  - skarap 11y ago
    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.
technofiend 11y ago
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.

by pquerna 11y ago

skarap 11y ago

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.

AnthonyMouse 11y ago
> 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.
- skarap 11y ago
  > 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.
russell_h 11y ago
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
- skarap 11y ago
  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.

technofiend 11y ago

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.