How Browsers Store Your Passwords (and Why You Shouldn't Let Them)
raidersec.blogspot.in
raidersec.blogspot.in
Why aren't physically-local attacks in Chrome's threat model?
People sometimes report that they can compromise Chrome by installing a malicious DLL on a computer in a place where Chrome will find it and load it. (See https://code.google.com/p/chromium/issues/detail?id=130284 for one example.) People also sometimes report password disclosure using the Inspect Element feature (see e.g. https://code.google.com/p/chromium/issues/detail?id=126398).
We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your computer as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your computer, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome — all applications must trust the physically-local user.
Evidently, only 0.0085% of users toggle on the "Use a master password"
* I don't even know how to setup a master password and have never heard of the option being available in FF or Chrome. I also don't know what it does. Does it replace all password boxes with a master-password that you enter which then pulls down the appropriate password? Is it a keychain?
Saying "X people don't use this feature" could mean anything. It could mean the feature is buried in the system, or that the feature isn't descriptive enough, or that the feature is hard to understand... it doesn't default to being "people clearly don't want that feature".
[*] I could research it, but I'm giving you my current uneducated opinion to make a point.
Easy as pie.
"All you have to do is go to password settings and click the button"
And you only have to go there once ever.
I think it's usually assumed users can navigate menus, because even if they can't there's not much you can do to help them at this point.
It's right there in the security tab. TWO clicks.
1. open preferences
2. click on security
And it's RIGHT THERE. That's about as obvious as I can imagine it.
Go to Settings -> Show advanced settings -> Manage saved passwords -> Click on a "hidden" password -> Click on "Show" button -> Voila, password shown in plain text
Out of all the things Chrome does this is one of the most annoying.
However, that's certainly a good feature to mention!
As an analogy, say you have a house and you have a drawer where you keep all your secret information. If you really want to keep the information secret, then you shouldn't allow outside visitors inside your house. You could encrypt the secret information to make it difficult for the attacker to read the information. But he still has access to your drawer because you let him into your house. The attacker can install a remote camera near your drawer to see how you decrypt the information, or he can directly see the decrypted plaintext.
So, don't allow anyone into you house.
Front-end stuff is well outside my area of expertise, so I'm betting someone already tried these ideas and now browsers protect against them.
While it is undeniable that the OSX keychain adds a roadblock to the theft, many average users would happily enter their password if the box was displayed when they ran up their browser (even if the browser wasn't the originating process) and likely also fall for a fake keychain prompt.
I think the keychain is a good thing (just as it is in Android). Just wanted to make the point that the keychain for your average non-power user is a minor roadblock in theft, rather than a "real" security feature.
At least Chrome extends the supplied OS security features and doesn't try to re-engineer them from scratch. This makes me more comfortable with Chrome rather than less.
I'm not really sure there is really any defense yet devised for phishing attacks against 'average non-power users.'
I'm not disputing you though, I think it is a problem. But unrelated to how securely a given app stores sensitive info, which is what OP is about.
Firefox, out of the box, does _not_ use the OSX keychain even on OSX. Sadly. It ought to.
Short of making you log in to your browser/password manager with a master password every time, how can you possibly store and retrieve passwords without letting other programs running with exact same permissions as you retrieve them?
Of course, that's assuming all the software is well-behaved. You could have local malware that pops up a fake master password dialog, trick a user into filling it out, pulling the keychain out of the user's Library, then decrypting the whole keychain file manually.
Once there's malware running as the user himself, all bets are off. This is why iOS is probably the most secure OS out there - there's no chance for malware to get on the device.
Personally, I just disable all password storage on all browsers and use 1Password.
This is the airtight hatchway we're talking about. The post's premise, and the solutions for Chrome and IE, imply bad guys are already on the other side. All hope is lost. Best you can do is try and make it so that anyone just stumbling around rather than purposefully looking for the passwords doesn't find them, and the value of that is questionable on false sense of security arguments.
It's non-news to anyone who understands how Windows is built.
"Good question! You're right - in these cases it is assumed malware is already present on the system and running in the context of the user. But there can simply be better protection.
Consider Firefox's use of a Master Password. Even if an attacker is on the otherside of the airtight hatchway, he/she will not get the credentials unless they can find out the password used.
Thanks for the great comment!"
But yes, to answer your question (and to validate the other poster on this thread) - If malware infects your system, you will likely have a bad time.
There are scenarios where master passwords are extremely useful and that's passive file disclosure such as a network home directory, a compromise of another account while you're not logged in, or – particularly relevant these days – a breached cloud sync service. I would make the case for that reason rather than as a malware resistance measure.
The long term fix requires architectural changes: none of the attacks described work directly on Mac OS X because the Keychain decoding happens in the securityd process which runs as root so the malware would trigger a confirmation prompt for each password it tried to pilfer. Unfortunately, this is also less than perfect as most users check the “Always allow” box granting permission to their browser for unprompted access…
https://www.google.ru/search?client=opera&q=intitle:%22index...
Firefox would appear to be vulnerable to that approach. Not sure about Opera's wand.dat, probably vulnerable as well.
Why does Chrome, when the registration page includes both email and username fields, only remember the email but then insert it into the username field when you attempt to log in? I know some sites let you use the two interchangeably to login, but doesn't this seem like a silly assumption on Chrome's part? Why not remember both, and insert the username OR the email depending on what the field is called?
While it was intensely frustrating at the time I'm actually grateful that it is so hard to get an account. I provided considerable amounts of information, but it wasn't enough for them to hand it over.
Still, when I got access to my super secret hard copy of passwords, and loaded Chrome onto a new machine, and signed into Google, I was a bit alarmed by just how much stuff came back from them onto my local machine. I'm currently slowly migrating to Yubikey and a nice password safe and better passwords for everything.
That said, It's very good to know that Firefox is the safest of the three. If I ever again have the misfortune of advising windows users on the safest browser to use, I will definitely let them know that it would take far longer to compromise their passwords in firefox (even hours longer!) than the other browsers.
Myself, I'll stick to Firefox with the KWallet extension under Kubuntu.
1. The public key stored by the server cannot be used for authentication. That means that hacking a server will not give the attacker access to anything beyond that server.
2. More randomness; there are no dictionary attacks on secret keys, and brute force attacks are hard to mount.
3. Defense against phishing: the attacker cannot trick you into giving your secret key, because the card does not export secret keys.
All of the above address the biggest problems we have with passwords right now. You are not likely to be tortured for your card or your PIN, just like you are not likely to be tortured for your password. Sure, smartcards come with their own set of problems, like dealing with lost/stolen/destroyed cards; yet these are not terribly hard to solve (banks are able to deal with lost/stolen/destroyed credit cards). The benefits far outweigh the cost.
Which isn't to say that multi-factor auth isn't a good idea, it's just that certificates are still better than passwords.
...if there was a remotely exploitable browser bug that would make the browser leak them it would be a threat, but this post seems meaningless from a security pov.
Better still, let the phone do the public key cryptography (as in plan9's factotum), so that your private keys never leave your phone.
For my Web pages, the 800 pixels is wide enough to get the information out there for the users to read easily. For my Web site, that my Web pages are only 800 pixels wide and, thus, usually don't take up the full width of the user's physical screen helps the UI/UX.
Even if the user's screen is 4096 pixels wide and three feet wide, I still only need 800 pixels of their screen!
For users with tablets, phones, etc. my Web pages should still be easy to use.
Any suggestions as to what I could do to help you read the content?
The situation is very common on the Web now. My 17" monitor is from NEC years ago, is razor sharp and rock solid, and I see no great reason to take time out to change from it. Besides, as another comment in this thread noted, laptops also have relatively small screens! So do tablets and phones!
I know nothing about using Google's blogspot.
For the Web site I'm building, all screens are just 800 pixels wide, and all my fonts are nice and large. So, on a big screen, could have a 'pile' of dozens of such windows each offset a little, and on a small screen could still see the full width easily without using horizontal scroll bars.
How'd I do that? I'm a beginner at HTML but just stuffed in 800 px some places, and got 800 pixels. If in a browser I shrink a window to less than 800 pixels, then I get horizontal scroll bars.
Broadly it's easy to assume that there it's reasonable to use lots of space vertically and let the user do a vertical scroll but try to minimize space used horizontally so that a user doesn't have to do a horizontal scroll just to read the text.
In some cases, I just highlight the text, copy it to the clipboard, pull it into my favorite editor, and flow the text to, say, 60 characters a line.
My view is, in reading, 40 characters per line has some advantages in eye movement in reading, 60 characters per line is plenty, 72 is almost too many, 80 is about the upper limit, and over 100 is too often a problem and, really, for easy eye movement in reading, too much.
Heck, even when newspapers had sheet sizes big enough to cover a table top, they still kept way down the number of characters per line.
But I can't tell the world how to design Web pages. If some people want, say, 300 characters per line and 20 characters per inch on the screen horizontally, then so be it.
P.S.: Yes, some operating systems and browsers now zoom in a way that this doesn't matter so much, but not all, and not without downsides.
I don't know what to do about that yet.
If they have a way just to zoom my Web pages, then they will be okay.
But if they have a big screen with lots of pixels, then I don't want my Web pages taking all of that screen. It's better for the UI/UX for my pages to take less than the full screen so that my users can see some other screens while using my site.