Hacker News Reader

Comment by Rygian | Hacker News Reader

Newbie question here: how is a private key stored in a device I can easily lose more secure than a (long and sufficiently random) password that I've memorized and can type down only when intended?

View on HN

For one a key is not transmitted over the network but the bigger reason is that most people don't use sufficiently long, random and unique passwords. If you are running a server where only you SSH in and you use a long random and unique password you are probably fine but for most people it's just easier to use keys at that point since it is not a lot easier to use long random and unique passwords than it is to use keys.

One upside to keys is also that since the server does not have your private key you don't need to rotate it if that server is hacked so you can reuse the same key for multiple servers and services. If you reuse the same long random password it only takes one of those servers/services to be hacked for you to be compromised on all of them.

Adding to that, some servers might have a secondary user with a weak password that was created by an installer or an admin for testing purposes. Disallowing password login prevents others from exploiting these accounts.

Agreed, that's why I put "If you are running a server where only you SSH in" but maybe I should have been more clear about it.

If you plan to store your private key on a device you can loose the key itself should have a password too. So the attacker needs still a password to unlock the private key. This is actually a good idea in general. Securing the private key with a password.

Nitpick: passphrase, not password

Nitpick: if you have a password manager it doesn't matter

Well it kind of does.. A password is validated, and if you lose it there is usually some recourse. Reset or whatnot. It may be a hassle but always possible somehow.

If you lose a passphrase, no one can help you even if you hit HN front page and /r/all with a sob story. So backups and availability have a different cruciality.

Also if you store a private key on the same medium as a password store with weak encryption or key that contains the passphrase, they key can't be considered as strong anymore.

There are practical reasons to make a distinction and mistakes can be expensive.

Thanks, yes, passphrase is the correct word. :)

if you lose your key, make sure that local (not remote) login is the recovery method. locking yourself out is a real thing.

passwords all the way down. /s

passwords are a symetric key, hence if the server is compromised, so is the password. with asymetric keys, a compromise of the public key is no problem.

but you are right, key-files on a disk are more vulnerable to theft than secrets in your head. keyfiles with a password ontop are most secure but also most uncomfortable.

> passwords are a symetric key, hence if the server is compromised, so is the password

Pretty sure that’s not how it works, iirc passwords are stored one-way encrypted. And if it were true, then anyone with root access to a box could comprise every other (Unix) user’s key, which seems like a potentially bigger problem…

pretty sure passwords are sent to the server in a way that reveals the actual password to the server. any chance you are thinking about key-agent?

Passwords are (or rather should be) indeed stored using crypt. However at login the provided password needs to be compared to the hashed one, which means the clear text password needs to be rehashed. I am not sure this happens on the client.

It definitely doesn’t happen on the client. If it did then the server’s password file would effectively be plaintext.

> If it did then the server’s password file would effectively be plaintext.

Send seed and hashing parameters to the client, then client does hashing, client sends hash, server compares hashes. It's vulnerable to replay attacks, but it's the same with client sending plaintext password to server (assuming that you're not using SSH or similar).

You two are working your ways towards defining a zero-knowledge password proof:

https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

I think SRP is the most widely implemented version. https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

Note that SRP is an older protocol, and things have moved on from there. See various PAKE algorithms:

* https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

Quick google led me to RFC4252[0], section 8 of which (as far as I understood) describes ssh auth sending password as UTF8 plaintext string (and the whole packet is encrypted at transport layer). While passwords in /etc/shadow are hashed, if someone got access to your server he can just put malicious listener that will catch this UTF8 string.

I'm not a SSH guru, so if I'm mistaken please shout at me ;D

[0] https://datatracker.ietf.org/doc/html/rfc4252#section-8

Anything that is not PAKE (which SSH is not) generally sends the password to the server:

* https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

* https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

   A Password-Authenticated Key Exchange (PAKE) attempts to address this
   issue by constructing a cryptographic key exchange that does not
   result in the password, or password-derived data, being transmitted
   across an unsecured channel.

* https://datatracker.ietf.org/doc/html/rfc8125

I'm sure there are other zero-knowledge protocols besides PAKE-like ones, but I'm not an expert here.

I wouldn't worry about storage. Anyone with root access can modify the sshd daemon (along with imap, pop3, and whatever else) to log all the passwords received.

It's a good idea to encrypt devices you could potentially lose anyway. Besides private keys, they probably contain session tokens, API keys, and other things--especially those saved by the web browser (cookies, cache, local storage)

Use one key pair per device. If you lose the device, remove the associated public key from the server's authorized keys.

Using a password on they key isn't a bad idea either.

Reply on news.ycombinator.com