This article addresses a very serious and pervasive business data risk, so let’s get right to it:
The default password management features available in Chrome, Firefox, and Edge browsers only provide the appearance of secure password storage. In reality, they provide absolutely no meaningful protection for stored user passwords.
Business leaders take note: if your employees are using any of these browsers to store their work passwords, then you likely have a serious, easily exploitable security risk on your hands that requires your immediate attention. Your critical internal business data systems, vendors, and clients are likely far more exposed to a data breach than you should be comfortable accepting.
TL;DR? Then please watch this first:
VIDEO
Is your business at risk? Let’s assume your employees are doing the right thing and creating complex, random, and unique passwords for all work-related accounts. But, they have a lot of them: one for corporate email, one for Dropbox, one for a vendor’s ordering platform, one for your HR portal, one for AWS, and so many more for all the business services they use to do their work.
You now need to ask yourself this one basic question:
“How do our employees store their work related logins and passwords?”
Maybe you’re not sure, and if you haven’t previously provided any guidance or tools for them to use, then your average employee is probably doing one of these three things:
Writing passwords down on paper
Saving passwords in a document on their computer
Storing passwords in their browser’s built-in password manager
Hopefully, you have a corporate security awareness training program and have long been discouraging the first two practices, even if some people may still do them.
It’s probably a safe bet then that most employees are using their browsers to store all of their long, complex passwords. While not perfect, many companies have accepted these built-in features as “secure enough.” And since browsers are constantly volunteering to save every password the user enters, it shouldn’t be surprising then if this is how your employees are keeping track of them.
So what’s the problem? It’s reasonable to assume that an out-of-the box, default feature in a major brower should be pretty secure … except when it’s not, by design!
Here’s what we mean:
Even though Chrome, Firefox, and Edge browsers all store passwords in encrypted databases, by default all three products intentionally leave the associated encryption keys completely unprotected in predictable locations .
To be perfectly clear, encryption is worthless if the keys aren’t secured. An encrypted password manager database with an unprotected key provides no meaningful protection at all for your passwords.
It may be difficult to believe that three major browsers all have intentionally included a feature that is so egregiously insecure. It just doesn’t make any sense!
Even more surprising, all of these browsers actually have mechanisms to protect their keys, by setting an additional “master” or “primary” password – but it’s not turned on by default and the browser never prompts the user to activate it!
So why in the world are they designed this way? Most likely, it’s because this is the easiest way for browsers to start prompting you to save passwords, without the extra burden of forcing users to first set the master/primary password to protect the encryption key. And once you have a few passwords saved, you’ll be less likely to switch and start using another browser.
While defaulting to this insecure storage method is bad enough, the even more inexcusable design flaw is never warning the user that they’re using an insecure storage method. This gives the impression that everything is OK, which is a truly awful security design!
Think about it this way – you can put the strongest locks on every door of your house, and make sure they’re all locked tight, but you then put the key under the doormat because that’s what all your neighbors do. It may “feel” like you’re secure, but are you really? If a thief can easily guess exactly where to get your key, then of course not!
The consequence of this browser design is that if anyone gains access to an employee’s system, through phishing, malware, or any other exploit, then they can easily extract all usernames and passwords stored by their browser. It’s a trivial exercise to exploit this flaw, as we’ll demonstrate shortly.
See it to believe it To be honest, we had a hard time believing this flaw was really this easy to exploit when this first came to our attention . We’ve never been all that comfortable with the security of built-in browser password managers, but we’ve always assumed that any exploit would at least need to leverage a bug in the browser or require advanced technical skills.
But nope – it took literally just one hour to research and build a sandbox environment to confirm the flaw, with no special skills or technical tricks required at all.
See it in action for yourself:
VIDEO
In this short video, we demonstrated how simple it would be for a bad actor to exfiltrate passwords from an employee’s Chrome, Edge, or Firefox browser running on a Windows desktop. We use each browser to create an account on a real website, and then a command line script is run to decrypt each browser’s password database and list the contents, showing the username and passwords that were just entered.
To put this in perspective: it is actually worse for employees to use one of these browser password managers than just using a random Word or Excel doc to manually store their passwords – a practice you’ve likely been harping on your employees not to do for years. To understand why that is, just ask yourself what’s more likely – that a criminal will put in the work to comb through a compromised OS to maybe stumble upon someone’s personal document with stored passwords, or instead, just smash-and-grab the browser password manager files that are sitting unprotected, exactly where they’re supposed to be ?
The bottom line: complete, unfettered access to all stored passwords!
What does this mean for my company? Business leaders need to accept that employee account credentials (usernames & passwords) are just another form of critical business data – same as your source code, customer production data, or HR records – and they really need to be managed with the same protections and precautions.
Many companies don’t fully recognize this fact and treat their employees’ saved credentials more like a form of semi-personal data. The company may establish some ground rules – password complexity, rotation requirements, etc. – but generally speaking if someone’s accounts are compromised it’s usually viewed as an individual’s problem and not an inherent risk to the business.
This is very shortsighted and can quickly become problematic. Imagine these scenarios:
Your company is targeted by a cyber extortion gang, and a successful phishing attack has now allowed a low profile malware infection to spread on your corporate network. The malware’s only mission is to exfiltrate browser databases and keys, and just like that, nearly every employee’s password repository is compromised, opening the door for a massive data breach.
A spear phishing attack on your CFO leads to a compromised password manager containing their email login credentials, and before you know it you have a business email compromise (BEC) situation on your hands. Clients start to report that they’ve sent their quarterly payments to a new offshore bank account because they received what looked like a very legitimate email from your CFO’s mailbox telling them to use a new bank routing number, and that’s just the beginning of your headaches.
This is how business nightmares happen!
What should we do to manage this risk? If you are a business security leader, you have an obligation to protect all business data, including employees’ credentials. It may be alarming how this issue is sitting in plain sight, but now that you know about it you must take action to mitigate the risk to your company. You need to provide a safe and effective way for your employees to store their credentials and get them to use it, quickly.
The most straightforward way to address this is to deploy a secure, dedicated password manager product for employees to use, such as 1Password, Bitwarden, LastPass, or Keeper. Enterprise versions of these products will provide you centralized control over password security, and will make it easier to share credentials safely when needed. Selecting a specific vendor is beyond the scope of this article, but be sure to carefully consider user management features and two-factor authentication options.
Note – many of these dedicated password managers have browser plugins or extensions to help users save and fill passwords. These are very different and much more secure than the built-in password managers that are the subject of this article!
You could try to just force employees to protect their encryption keys by setting a master/primary password mentioned earlier, but it can be a lot of work to set up and difficult to manage – it’s usually better in the long run to just deploy a dedicated password manager for your employees, even though there may be a subscription cost.
Still not sure where to start? We have developed a basic remediation plan that can be adapted to fit your organization’s needs.
Suggested Action Plan
Step 1 – Quickly assess your risk.
Gather up your IT & Security team to help understand how complex of a problem you’re facing.
Ask your team these questions:
When was the last time password storage guidance was updated and sent to employees, if ever?
Does your company mandate what browsers are acceptable? Are employees allowed to install and use whatever browser they wish? Do you have a software inventory system that can show you how many different browser installations you have across the company?
How do IT and Cloud Ops teams share non-individual passwords, like service accounts or root logins?
Is anyone aware of any employees already using dedicated password managers on their own initiative?
What are the most critical business systems that need to have their logins protected?
Where do we mandate the use of 2FA / MFA or SSO to log into critical systems?
Step 2 – Set temporary policy
If there is a significant risk of employees using insecure browser password managers, then draft a clear and concise emergency policy that mandates:
Anyone using Chrome, Firefox, or Edge to store passwords must enable the “master” or “primary” password encryption feature.
Any password stored in a browser before this feature was activated should be considered suspect and must be reset. All passwords for critical business systems [provide list] must be reset within [“x”] days, and all others must be reset within [“y”] days.
All employees are discouraged from storing additional passwords in their browsers, but may do so as needed provided the conditions above are met.
Employees who fail to adhere to this policy are subjecting the company to a potential security risk and may be subject to disciplinary actions. [or substitute your standard policy compliance language]
Step 3 – Communicate policy changes
Announce the new policy to employees, and include instructions about how to set the encryption feature for relevant browsers.
Ensure that your IT team is prepared to assist employees with configuration changes.
Communicate with the people who onboard new employees so they can be trained on the policy when they start.
Follow up over multiple days using various channels (email, town halls, manager meetings, etc.) to emphasize the importance of the policy and to promote adherence. Consider requiring employees to positively confirm to their manager or to IT that they have taken the necessary steps outlined in the policy.
Step 4 – Develop long term solutions
Gather primary stakeholders to establish functional requirements for a dedicated password manager and commission a small team to pilot and evaluate different vendors. Pay careful attention to security and management features while evaluating. The ability to centrally enforce the use of 2FA / MFA with the product should be a non-negotiable requirement.
There are a few products that have free tiers, which may be a cost-effective choice for mass deployment across a large, cost-sensitive organization. Be aware though that most of the time the free tier options are for individual use only, so you will likely have no management oversight over their use (for example, requiring 2FA / MFA to be activated).
Once you select a product, invest heavily in developing employee training materials and administration guides for your IT teams before general roll-out to employees. Make sure everyone understands what IT can or can not do to help employees who have forgotten their primary encryption password.
Develop an audit plan for any shared password repositories. Ensure that only the right people have access to shared passwords on at least a quarterly basis.
Work with the people responsible for employee onboarding and offboarding so that new employees are trained on how to use the password manager and so that access for terminated employees is promptly removed.
Wrapping up A word about “insecure by default.” Throughout this article, it’s mentioned several times that the browser password managers are insecure “by default.” They don’t have to be this way – it was a choice by the manufacturers (Google, Mozilla, Microsoft) made to configure them in a way to maximize convenience by completely compromising encrypted storage.
As mentioned earlier, all three browsers already contain mechanisms to protect their encryption keys. This is done by setting a “primary” or “master” password – essentially, one password you memorize that is used to help encrypt all of your other saved passwords. None of them functionally require this to be the default behavior though – which is awful because they certainly know that most users don’t understand how this works and will never bother to activate it manually, leaving billions (yes that’s billions with a B!) of users at risk.
The solution to this problem is obvious – all that Google, Mozilla, and Microsoft need to do is flip the default behavior so that an encryption password is required. If you still want to give users an option to not use the encryption password, so be it, but they should be required to manually deactivate the configuration (with plenty of strongly worded warnings about how insecure it is).
Dedicated password manager products (LastPass, Keeper, 1Password, etc.) always default to requiring an encryption password, with 2FA optional (but strongly recommended).
What about MacOS and Safari? The Safari browser is tightly coupled with the Apple ID security functions in MacOS and does not have this same design flaw, so kudos to Apple on this point. Still, even if your company already uses MacOS laptops, it’s unlikely that outlawing Chrome and Firefox is going to be a popular mandate with your employees.
The exploit scripts shown in the video demo required Windows-specific Python modules and were only tested on browsers installed on Windows. We were unable to locate scripts to perform the same exploit for Chrome and Firefox browsers installed on MacOS. However, the way both browsers store their internal data is very similar on both operating systems, so it is likely that MacOS installations are susceptible to this flaw as well, assuming similar Python decryption modules are available or can be written for MacOS.
Thanks for all this, but we already use a dedicated password manager. That’s great, but you might still be at risk. By default, the built-in browser password managers are so annoyingly persistent about asking to capture passwords that it’s very likely that your employees have either accidentally (or intentionally) saved some in one.
For organizations that have identified an approved browser they encourage employees to use, then you should take the extra step to ensure that its built in password manager is turned OFF, either by an enforced technical policy, or by configuring it for the employee before their laptop is issued. Chrome , Firefox , and Edge all have ways to do this fairly easily if you have centralized configuration policy enforcement.
Can you show how you tested this flaw? We are intentionally not revealing details that show how the exploit scripts work or where they were obtained. This article is not intended to serve as a tutorial on how to perform this exploit. Our goal is only to raise awareness with the business community about this pervasive data security risk.
All scripts were found freely online and modified only slightly for display purposes. Please contact us directly if you have a legitimate interest and would like additional information on how this proof of concept was performed.
Please note that we are business security advisors providing vCISO services , not general security researchers or Python developers. Feedback to improve this article is always welcomed. If you are knowledgeable about how Python uses MacOS encryption APIs to decrypt files in a similar way to Windows, please let us know and we’ll update this article.
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.
