Hacker News Reader

Comment by YellowRex | Hacker News Reader

Other side of an airtight hatchway? For this to be at all relevant, you're already got me running your binary with my user's permissions.

View on HN

Or, for example, attacker stole your backup via vulnerability in your NAS. Or, for example, some idiots share whole system volumes in e2k and Direct Connect networks. Or ever web:

https://www.google.ru/search?client=opera&q=intitle:%22index...

Just getting the file would not help you for the attack vectors shown in the article for Chrome (need user account's CryptProtectData), IE-pre-10 (need copy of registry keys + CryptProtectData), or IE 10 (need binary on user account).

Firefox would appear to be vulnerable to that approach. Not sure about Opera's wand.dat, probably vulnerable as well.

Opera allows you to set up a master password, if you want it. If you don’t want it, you can copy around wand.dat as you like (even from your computer to your phone!) and it just works. :)

Hi there! Thanks for the great comment. I had a similar one on my blog that I responded to in the following way (I hope it helps!):

"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 if there is already malware on the user system, it just needs to wait until the user authenticates once in Firefox to get the master password, then it can fetch all the other passwords. Right?

Yes, precisely. Local running malware = owned, period.

Absolutely it could. However, the layer of defense provided by a master password is still (so far, seemingly) better than the instantaneous and automatic access to credentials malware could have when extracting credentials from Chrome and IE.

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.

I think you're answering in good faith but I find that caveat so overwhelming that it makes the point meaningless: if malware runs locally outside of a sandbox, you're screwed – full stop, end of story.

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…

Which, according to his findings with the dumpmon twitter bot, is not uncommon. Obviously you can make the case that YOU would use anti-virus software and YOU wouldn't let malware be installed on your computer, but in the end, you're still using a fairly insecure method to store your important passwords. And really, wouldn't a solution like LastPass be better in every way anyway?

I remember some software explicitly storing your saved passwords in plain text to make the point that storing it "encrypted" is in the end no different.

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?

You may be thinking of Pidgin: https://developer.pidgin.im/wiki/PlainTextPasswords

The Mac OS X Keychain[1] acts as a gatekeeper and has fine grained permissions so you can let one application have default access to certain passwords (e.g., web passwords) but not other (IMAP/local file shares), or even to require the app to prompt you each time the app wants access to a password.

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.

[1] http://en.wikipedia.org/wiki/Keychain_(Apple)

Isn't this just the standard 'Windows is woefully insecure' problem? I would be curious to see how this works in the browsers on OS X.

On OS X, the passwords are probably stored in the Keychain which would be much better than this.

Personally, I just disable all password storage on all browsers and use 1Password.

Firefox will use the OSX keychain only if you install Keychain Services Integration: https://addons.mozilla.org/en-US/firefox/addon/keychain-serv... . I highly recommend it.

Like I said, I opt to use 1Password instead for cross platform usage.

Same here, amazingly happy with LastPass and it even makes logging in on mobile a breeze :)

So locally running malware only needs to keylog your master 1Password password to decrypt your 1Password data file?

This is harder than it used to be due to the secure text entry and sandboxing options which OS X has added but it's definitely the biggest risk for password manager users.

If you have a keylogger on your machine, all hope is lost. This is true for any password based security, much like a the best safe in the world is thwarted by someone videotaping you entering the combination. Even so, 1Password does utilize sandboxing in OS X and a secure desktop in Windows, which should in theory make this significantly harder to achieve.

Yes... and the premise of the original post was about vulnerability to arbitrary code being executed on the machine with the user account's rights. I.e., nothing's stopping the keyloggers now.

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.

Chrome OSX stores in OSX keychain out of the box.

Isn't that what the #poopin tweets are about? You're always going to let the hatchway open once by accident.

Reply on news.ycombinator.com