This is terrible general security advice, as well as a failure in threat modeling.
The point of the (very usable!) built-in password manager is to fight phishing and password reuse, which are each orders of magnitude bigger problems than endpoint compromise, which is the attacker position this article relies on. That alone makes this dangerous advice.
But even if you are somehow focusing on endpoint compromise, on desktop systems the malware can just wait for you to type the password manager master passphrase, and exfiltrate the entire vault. Not 12 lines of code, but maybe 120. In fact, there’s a better argument for calling the latter approach “security by obscurity”; I wouldn’t call using SQLite an attempt at obscurity at all.
In practice, the passwords that matter are the system FDE one for encryption at rest (which protects the browser passwords as well as the rest), and the sync password to protect the contents from the cloud provider, which the browsers correctly implement.
The only thing requiring a master password to be typed to unlock the vault locally would do for most users is degrade UX, reducing adoption, and provide a false sense of security (because again if the endpoint is compromised, it will fall to keyloggers or memory inspection).
Its annoying how so much of this “security advice” is about stuff where you have already been compromised and there are already 100 other ways to get the data or its about such insane things like “Out of office emails are a security risk” because someone might send you and email and then know they can launch an attack while you are on holiday..
In practice, the passwords that matter are the system FDE one for encryption at rest (which protects the browser passwords as well as the rest), and the sync password to protect the contents from the cloud provider, which the browsers correctly implement.
Firefox doesn’t implement the second properly: passwords are encrypted using a key which is a simple function of the password (which means that Mozilla can attempt to crack them, and will be successful for simple password like ‘open sesame.’
Worse, they don’t even have to do that: they sometimes prompt for Firefox passwords on web pages, which means that they can just steal your plaintext password there.
Sadly, Firefox used to have a password storage system which really was secure against Mozilla being malicious.
I think that Chrome is very slightly better here, because the password-encryption password is never shared with Google.
I completely agree with everything else you write, though.
But we don’t care that it’s trivial for an attacker to recover cookies?
If you were to steal, for example, my github password, you won’t be able to login without my yubikey. But if you steal my cookie, you are logged in. Why do I care more about malware stealing something that isn’t useful than something that is?
This has always worried me. I run my web browser as a separate user and lock down all profile data to that user. It’s not perfect, but at least all applications run using my regular user can’t access my cookies. I’m not sure why this isn’t standard practice.
I don’t like his clickbait title: he doesn’t give a method to extract cleartext passwords from Firefox.
Maybe he’s still trying to decode the logins.json file, where usernames and passwords are encrypted. Yes, you have to browse Firefox sources to know how to do.
So if an attacker is able able to run arbitrary code on my system, they could choose to decode the password file from my Firefox profile instead of installing a keylogger that will be successfull in many more systems or attack my actual password manager?
Tbh, if someone can run arbitrary code on your computer, there is very little that any modern security solution can do to actually prevent them from pulling your passwords and bitcoin wallet.
After reading the comments in the thread, I apologize for submitting this article. It was definitely a mistake.
I was not trying to spam in any way, nor am I in any way affiliated with the author or his company. I submitted this article because I thought it was interesting, more specifically the method in which he extracted the passwords in plain text.
Hey don’t worry about it, I also thought the script and the format of data storage for the passwords was interesting. I also think that the holes in the article that other people are pointing out are interesting. You’ve started a fun discussion!
I find the difference in quality of posts submitted to lobste.rs astonishing. On the one hand, there are great and insightful articles about PLT, cool new concepts like NixOS, pijul, formal methods and so many other interesting things. On the other hand there is this, where a startup CEO gives a big rant on hackernoon that only states the obvious (an attacker can do pretty much if he compromises your computer, duh) and gives harmful security advice.
Firefox’s Master Password function is… not great. It’s buggy and it can be broken. I can’t find a source right now but if memory serves, both of those are part of why Master Password had been on the verge of being removed for years.
I personally turned it off years ago because it was annoying and because as @FiloSottile and @tadzik have pointed out so eloquently, it doesn’t really add any value. I haven’t looked back.
This should really come as no surprise to anybody. Reminds me of this piece by esr, written who-knows-how-many-years-ago about fetchmail:
Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn’t be able to casually see them.
I didn’t do it, because this doesn’t actually add protection. Anyone who’s acquired permissions to read your rc file will be able to run fetchmail as you anyway—and if it’s your password they’re after, they’d be able to rip the necessary decoder out of the fetchmail code itself to get it.
I’d be curious if the author knows any way of encrypting the password in such a way that the encryption key is not available on the hard drive and yet can pull the passwords out by itself :)
Sure, you unlock the “vault” using a KDF such as PBKDF2 or Argon2. Ideally the “password” is the same as the login password, so that the user doesn’t have to enter it twice. You then keep this key in memory until the computer suspends.
This works great if your threat model is offline disk access. There is really no way to do it if your threat model includes other programs running as the user in question.
I’m not sure the two compare. Fetchmail config would not be unlocked in any way, whereas a password database could be locked behind the user’s main account password.
The author assumes the attacker has access to the user account, but what of they don’t? What if they came in through a browser exploit?
Having the database encrypted sounds like it would at least make extracting its contents more difficult. (Possibly has portions in memory somewhere?)
This is terrible general security advice, as well as a failure in threat modeling.
The point of the (very usable!) built-in password manager is to fight phishing and password reuse, which are each orders of magnitude bigger problems than endpoint compromise, which is the attacker position this article relies on. That alone makes this dangerous advice.
But even if you are somehow focusing on endpoint compromise, on desktop systems the malware can just wait for you to type the password manager master passphrase, and exfiltrate the entire vault. Not 12 lines of code, but maybe 120. In fact, there’s a better argument for calling the latter approach “security by obscurity”; I wouldn’t call using SQLite an attempt at obscurity at all.
In practice, the passwords that matter are the system FDE one for encryption at rest (which protects the browser passwords as well as the rest), and the sync password to protect the contents from the cloud provider, which the browsers correctly implement.
The only thing requiring a master password to be typed to unlock the vault locally would do for most users is degrade UX, reducing adoption, and provide a false sense of security (because again if the endpoint is compromised, it will fall to keyloggers or memory inspection).
Its annoying how so much of this “security advice” is about stuff where you have already been compromised and there are already 100 other ways to get the data or its about such insane things like “Out of office emails are a security risk” because someone might send you and email and then know they can launch an attack while you are on holiday..
Firefox doesn’t implement the second properly: passwords are encrypted using a key which is a simple function of the password (which means that Mozilla can attempt to crack them, and will be successful for simple password like ‘open sesame.’
Worse, they don’t even have to do that: they sometimes prompt for Firefox passwords on web pages, which means that they can just steal your plaintext password there.
Sadly, Firefox used to have a password storage system which really was secure against Mozilla being malicious.
I think that Chrome is very slightly better here, because the password-encryption password is never shared with Google.
I completely agree with everything else you write, though.
But we don’t care that it’s trivial for an attacker to recover cookies?
If you were to steal, for example, my github password, you won’t be able to login without my yubikey. But if you steal my cookie, you are logged in. Why do I care more about malware stealing something that isn’t useful than something that is?
This has always worried me. I run my web browser as a separate user and lock down all profile data to that user. It’s not perfect, but at least all applications run using my regular user can’t access my cookies. I’m not sure why this isn’t standard practice.
I don’t like his clickbait title: he doesn’t give a method to extract cleartext passwords from Firefox.
Maybe he’s still trying to decode the logins.json file, where usernames and passwords are encrypted. Yes, you have to browse Firefox sources to know how to do.
Also, what about Opera? And other browsers?
Is there a way to blacklist Hackernoon, and, heck, the whole Medium in general, from the feed here?
https://lobste.rs/s/bykzkm/hide_medium_com_as_personal_filter_on
So if an attacker is able able to run arbitrary code on my system, they could choose to decode the password file from my Firefox profile instead of installing a keylogger that will be successfull in many more systems or attack my actual password manager?
Tbh, if someone can run arbitrary code on your computer, there is very little that any modern security solution can do to actually prevent them from pulling your passwords and bitcoin wallet.
Hi Guys,
After reading the comments in the thread, I apologize for submitting this article. It was definitely a mistake.
I was not trying to spam in any way, nor am I in any way affiliated with the author or his company. I submitted this article because I thought it was interesting, more specifically the method in which he extracted the passwords in plain text.
I should have been more careful.
Hey don’t worry about it, I also thought the script and the format of data storage for the passwords was interesting. I also think that the holes in the article that other people are pointing out are interesting. You’ve started a fun discussion!
I find the difference in quality of posts submitted to lobste.rs astonishing. On the one hand, there are great and insightful articles about PLT, cool new concepts like NixOS, pijul, formal methods and so many other interesting things. On the other hand there is this, where a startup CEO gives a big rant on hackernoon that only states the obvious (an attacker can do pretty much if he compromises your computer, duh) and gives harmful security advice.
If this worries you then you need a Master Password in Firefox.
Firefox’s Master Password function is… not great. It’s buggy and it can be broken. I can’t find a source right now but if memory serves, both of those are part of why Master Password had been on the verge of being removed for years.
I personally turned it off years ago because it was annoying and because as @FiloSottile and @tadzik have pointed out so eloquently, it doesn’t really add any value. I haven’t looked back.
This should really come as no surprise to anybody. Reminds me of this piece by esr, written who-knows-how-many-years-ago about fetchmail:
Source: http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html
I’d be curious if the author knows any way of encrypting the password in such a way that the encryption key is not available on the hard drive and yet can pull the passwords out by itself :)
Sure, you unlock the “vault” using a KDF such as PBKDF2 or Argon2. Ideally the “password” is the same as the login password, so that the user doesn’t have to enter it twice. You then keep this key in memory until the computer suspends.
This works great if your threat model is offline disk access. There is really no way to do it if your threat model includes other programs running as the user in question.
I’m not sure the two compare. Fetchmail config would not be unlocked in any way, whereas a password database could be locked behind the user’s main account password.
The author assumes the attacker has access to the user account, but what of they don’t? What if they came in through a browser exploit?
Having the database encrypted sounds like it would at least make extracting its contents more difficult. (Possibly has portions in memory somewhere?)
Wondering out loud here, not an expert.
Make sure not to enter any passwords on your computer because if it’s infected with malware they could sniff your input devices. Or something.