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.
Browsers need to store the passwords in plaintext, because they need to populate the password field when you visit that website. However, you can store them encrypted using a master password and decrypt them once per session.
And, on OSX at least, every browser does this anyway, since the Keychain is right there to make use of and unlocking it is built into the OS. I'm really surprised Windows has no equivalent to this.
You're using Keychain correctly, but using your computer's authentication system incorrectly. Desktop environments in general (in Windows, OSX, Linux, etc.) assume that you will lock your session whenever you are not present and in control of the computer. (Thus, Keychain locks when the session is locked.) This is currently a big hassle to do, but all other security on the system is built up around that concept.
Really, PCs need something like TouchID. Or something like pairing to your phone, and then detecting it in proximity and prompting a TouchID confirmation from it. Phone goes out of proximity = computer locks.
I've found setting up a hot corner (I use the bottom left on OS X) works well for locking quickly. Quick flick of the wrist locks it no matter where the cursor is, and unlocking it is basically muscle memory for me.
I don't wish to encourage to culture of phone over-attachment.
I am not tethered to my phone, and I don't wish to be. It's always around here, somewhere, but not on my person unless I'm out of the house. If I get up, it is going to usually stay on the table. If I go upstairs, unless I'm using it, I'll probably leave it downstairs. I am not going to worry about keeping it in close proximity to keep my computer unlocked.
A lot of ThinkPad models have fingerprint scanners. The software connected to it sucks big time, as pretty much all oob software shipped with ThinkPads, but the hardware is there, and locking/unlocking with fingers works pretty decently. I guess we'd have to wait for Apple to discover it and fanfare it as the latest greatest invention to get any mindshare adoption of it though.
It's a big hassle because many of the things that cause you to get up from your computer will both distract you and require your hands: spilling coffee on the table and running to get a paper towel to wipe it up with; stopping your baby, in the same room, from touching something they're not supposed to; retrieving the next season-DVD of a TV series from your bookshelf. It would be far better if the computer "failed safe", so to speak.
Auto-lock/"screensaver mode" (wow, remember when computers had screensavers?) sort of does this, but the time the computer is most vulnerable (especially in any semi-public setting) is right after you dash away, not after it's been sitting idle for 15 minutes. When a computer's owner could come back at any minute, the best time for a social engineer to strike is the moment the owner leaves.
The last case especially (watching a marathon of some show with some friends) reveals an interesting bit of etiquette: it's rude to lock your computer in front of friends--it implicitly suggests they're likely to mess with it, and that you don't trust them enough to mess with it in a way that's merely funny, rather than potentially harmful. The great thing about an automatic proximity-based lock would be that, in going to the bathroom or whatever, the computer would always lock--so there'd be no decision to make which could be read into. (This is oddly similar to rhetoric regarding the incentive-structures of birth control pills vs. condoms.)
A browser has to be able to supply clear-text passwords to websites, so strong hashing and discarding the clear-text won't work in their use-case. Your router only need to authenticate your password, so it _should_ be using bcrypt/scrypt/pbkdf2 to hash the password and not storing it anywhere in clear-text.
