41–50 of 315 posts
To those saying this isn't insane... you are wrong. I can open anyone's chrome browser and access their passwords without a master password? That's plain fucked up. (I realise I could visit sites and use password reset, but this is so frictionless as to be insane)
I just did a little digging just by visiting some sites I've saved passwords for (in Safari) using Chrome. Chrome (on OS X at least) doesn't seem to actually store them in plaintext per-se, but what it does do is equally creepy. When you visit a site (i used twitter.com for my test) Chrome will attempt to access any Keychain items matching that location - you should get the stanrdard Keychain Access dialog prompting…
This probably is a mistake, far from harmless, but wouldn't it be better to point it out to the Chrome team and try to get it fixed. Have you logged a bug? https://code.google.com/p/chromium/ or Tools > Report an issue...
Shock! Firefox is insafe too! Call the presses, write the blogs! Go to any page where browser (Chrome or Firefox) pre-fills password. Click on the password, click on "inspect element", change the type of the form input from "password" to, say, "pasword". You just broke the internet security.
For completeness (I assume the answer is yes, but since you weren't clear): Does FireFox have a corresponding settings page with the list of all of the pages it knows a password for?
Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input. Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same has…
Having would work better than yours, I think?
There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time.
But aren't we just re-implementing client-side SSL certifications?
Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input. Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same has…
Earlier quoted context omitted.
They're not stored in plaintext, they're stored in the Keychain. The point here is Chrome provides essentially unauthenticated access to the Keychain. For reference, here's what Safari prompts you with when you try to view your saved passwords: http://imgur.com/k2gIqtM
"Unauthenticated" except for the time you told Keychain to "Always allow" requests from Chrome. However I'll admit that there's a big difference between what I expected Chrome to be using those passwords for (logging me into websites) and how it's ended up (making those visible to anyone looking at the settings page).
1. that does not make it OK to display all cleartext passwords, Keychain requires the account password before displaying the cleartext. And keychain can optionally require the master password to be entered before providing a password for form-filling as well.
2. an other user notes above that, whether you "allow" or "always allow", Chrome will copy the entry it just got to a new keychain entry which it sets to always allow.
On KDE chrome asks me my kwallet password (local keychain) every time ... Maybe this "complication" is too much for a stsndard MacOS user ?