Think of it this way. If you created a private key and uploaded it to a public website where everyone could get to it (say you posted it to HN ;-), how exactly is your system less secure than with password based auth?
You still need a passphrase to decrypt the private key. If you bump up the number of trials, you can make decryption even slower. It's going to be harder for someone to crack that than a normal brute force against a password.
Now, if you put that key behind a decently secure storage service that you use TFA to access, that's actually way more secure than just using a password.
Given that, the question ought to be whether you upload the private key to the cloud, or try to manage the private key yourself. Password based authentication shouldn't be one of the options you are considering.
No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.
In general, because you tend to have so much more entropy in a private key phrase (you only need one for multiple logins), and because the private key itself is a nastier nut to crack, the computational effort needed to crack a private key file is just nastier than the password crack. That's the whole point of the design.
Umm... if they are massively distributing the key cracking effort, spawning TCP connections isn't going to be a limiting factor... There is no requirement that the TCP connections be opened sequentially.
They will have to do a session/key exchange hand shake each time, but that shouldn't be more painful than the extra work needed to crack a private key with tons of trials.
Comments
Think of it this way. If you created a private key and uploaded it to a public website where everyone could get to it (say you posted it to HN ;-), how exactly is your system less secure than with password based auth?
You still need a passphrase to decrypt the private key. If you bump up the number of trials, you can make decryption even slower. It's going to be harder for someone to crack that than a normal brute force against a password.
Now, if you put that key behind a decently secure storage service that you use TFA to access, that's actually way more secure than just using a password.
Given that, the question ought to be whether you upload the private key to the cloud, or try to manage the private key yourself. Password based authentication shouldn't be one of the options you are considering.
No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.
In general, because you tend to have so much more entropy in a private key phrase (you only need one for multiple logins), and because the private key itself is a nastier nut to crack, the computational effort needed to crack a private key file is just nastier than the password crack. That's the whole point of the design.
Umm... if they are massively distributing the key cracking effort, spawning TCP connections isn't going to be a limiting factor... There is no requirement that the TCP connections be opened sequentially.
They will have to do a session/key exchange hand shake each time, but that shouldn't be more painful than the extra work needed to crack a private key with tons of trials.