Timeline for Why is using an SSH key more secure than using passwords?
Current License: CC BY-SA 3.0
4 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Oct 11, 2014 at 21:41 | comment | added | cpast |
@TheSpooniest Kerberos does not need to store a plaintext password on the KDC; it encrypts the ticket not with the user's password, but with something derived from the user's password, preferably with a one-way function. Compromising it compromises accounts within that Kerberos realm (the derived key is all an attacker needs to authenticate), but doesn't let an attacker use compromised passwords to attack independent services any more than compromising /etc/shadow would.
|
|
Oct 11, 2014 at 11:45 | comment | added | The Spooniest | Actually, not all password systems transmit the key over the network. Kerberos, for example, does not: instead, anyone who claims to be the user gets sent a ticket, but the ticket is first encrypted with the user's password. So it has to be decrypted on the client side before it's good for anything, and for that, the password needs to be correct. This gets around needing to send the password over the network all the time. On the other hand, it means that you have to have one machine which stores all the passwords in cleartext, so that machine has to be locked down hard. | |
Oct 10, 2014 at 22:05 | comment | added | user42178 | You seem to think that a password of the same entropy as a key has the same security as that key, but that's incorrect since a password, no matter how long is still transmitted to the remote server where as a key isn't. Connect to a rogue server with your password and it gets stolen, connect with a key and the rogue server can't do anything with it. | |
Oct 10, 2014 at 20:28 | history | answered | Shane Andrie | CC BY-SA 3.0 |