That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work.
The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.
I think they could however, as a default behavior, store each password encrypted individually using itself as a key, that way no plaintext passwords would need to be stored at all.
Yup that's right, my bad. I were thinking of a way of somehow not requiring input yet providing passwords without plaintext storage.
What would actually work I guess would be storing a hash of <the password, a unique string provided through https auth>. So for the first time the browser would hash the pass and afterwards just provide the pass to the server as a hash without requiring input, acting as a normal pass to the server. However, that would either require some sort of universal agreement among browsers to work, which is tricky to require, or some browser-server protocol in which the browser would only carry such procedure to supported servers. If a supported server is accessed through a non-supported browser, the server itself would perform the hash.
Probably too much of a hassle just in name of abolishing plaintext passwords on browsers, but I couldn't think of anything simpler. However, fun to imagine :)
Obs: This would have the extra bonus of depriving knowledge of plaintext passwords to servers (in case they are compromised, the attacker would not get to try the pass across other services) and preventing password extraction through impersonation of webpages (although this is already guaranteed by https to some extent).
If servers accepted a hash of a password instead of the actual password then the hash becomes the password. Ie, possession of the hash is equivalent to possession of the password since it can be used to authenticate.
Therefore, this is no different than storing them in plaintext. Furthermore, it would mean that if the hashes got stolen because a server was compromised those could be used as passwords and that would make it pointless to hash them in the first place.
And if you need to log in from a different computer?
All you are suggesting is replacing one password with another, harder to remember password. The system where the server only stores salted hashes and hashes your password server-side every time you log in is called "good practice". If you're allowing dedicated protocols and hard-to-remember keys, just use public/private keys.
Comments
That's different. Browsers need to show your password to external websites to prove to others that you're you. This requires storing the actual password. They expose saved passwords in the UI because if they didn't, it would create a false sense of security. There's always going to be some way to get the saved passwords, or the feature wouldn't work.
The router admin interface only needs to check your password. It can do that by storing only a cryptographic hash, not the password itself.
I think they could however, as a default behavior, store each password encrypted individually using itself as a key, that way no plaintext passwords would need to be stored at all.
Then you would have to type in the password each time you wanted to use it anyway. Not much sense in storing anything in that case. :)
Yup that's right, my bad. I were thinking of a way of somehow not requiring input yet providing passwords without plaintext storage.
What would actually work I guess would be storing a hash of <the password, a unique string provided through https auth>. So for the first time the browser would hash the pass and afterwards just provide the pass to the server as a hash without requiring input, acting as a normal pass to the server. However, that would either require some sort of universal agreement among browsers to work, which is tricky to require, or some browser-server protocol in which the browser would only carry such procedure to supported servers. If a supported server is accessed through a non-supported browser, the server itself would perform the hash.
Probably too much of a hassle just in name of abolishing plaintext passwords on browsers, but I couldn't think of anything simpler. However, fun to imagine :)
Obs: This would have the extra bonus of depriving knowledge of plaintext passwords to servers (in case they are compromised, the attacker would not get to try the pass across other services) and preventing password extraction through impersonation of webpages (although this is already guaranteed by https to some extent).
If servers accepted a hash of a password instead of the actual password then the hash becomes the password. Ie, possession of the hash is equivalent to possession of the password since it can be used to authenticate.
Therefore, this is no different than storing them in plaintext. Furthermore, it would mean that if the hashes got stolen because a server was compromised those could be used as passwords and that would make it pointless to hash them in the first place.
In other words, no, that wouldn't work.
And if you need to log in from a different computer?
All you are suggesting is replacing one password with another, harder to remember password. The system where the server only stores salted hashes and hashes your password server-side every time you log in is called "good practice". If you're allowing dedicated protocols and hard-to-remember keys, just use public/private keys.
It does make a lot of sense, actually, as you need to remember only one master key instead of multiple login-password combinations.
That's different from "using itself as a key", which is what the GGP said.