3 ms·

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

by 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.

by skarap 11y ago

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.