By acting as a phishing victim and their attacker, we put eight password managers to the test
Written by Chester Wisniewski
Editor’s note: This article is one of a three-part series exploring how secure internet users really are in 2021. Other articles in the series are, The state of World Wide Web Security in 2021, and Don’t fear the Wi-Fi.
It seems odd to imagine that one piece of software, which doesn’t even require a network connection, can improve the safety of your online life. But password managers certainly appear to fall into that category, though you do need be extra diligent in how you secure them! While performing research on modern Wi-Fi security, I was reminded how the use of a password manager became an important factor in the safety of insecure Wi-Fi connections.
More than just a memory store
The primary benefit of using a password manager when you may be on a network provided by an unknown or untrustworthy provider is to help prevent phishing and machine-in-the-middle (MiTM) attacks.
These attacks can often direct a victim to a fake look-a-like domain, tricking them into believing they are logging into Facebook, Gmail or another “credible” source. This is because the cybercriminals behind the look-a-like redirection attacks can obtain a Transport Layer Security (TLS) certificate for the fake domains.
Password managers know that a fake domain won’t match the exact domain used by a real service and, in general, will refuse to submit your credentials to attempted phishing scams.
There are other attacks that can occur over Wi-Fi though, so are password managers any good at helping prevent those attacks as well?
Putting password managers to the test
I decided to focus on two other attack styles: the downgrade attack and an attack that uses a fake certificate but still impersonates the real domain of the service provider they are trying to phish victims from, hoping the victim will bypass the browser warning.
For my test, I chose the eight most common ways of managing passwords: Google Chrome, Microsoft Edge, Mozilla Firefox, Apple Safari/Keychain, LastPass, 1password, Dashlane, and Bitwarden.
To conduct the test, I set up a fake website impersonating a popular news website that allows you to “sign in” to customize your news feed. The site uses TLS encryption but does not advertise a HSTS header. This allowed me to login to an account on the real site, store the password in the password manager tool and then perform both of my attacks.
Test 1: Password managers vs. unencrypted sites
The first attack was to hijack the DNS and redirect myself, aka the “victim,” to an unencrypted HTTP version of the site controlled by the would-be attacker. This would allow me to see if users on unprotected Wi-Fi could count on their password manager to protect them against this type of attack.
The first three I tested passed with flying colors. Google Chrome, Mozilla Firefox, and Microsoft Edge all refused to surrender my stored password. Next up was 1password and Dashlane, both of which didn’t fare quite as well, they warned me the connection was insecure, but if I clicked in the password blank, they did offer to fill it.
Only 1password explained in its warning that the original password had been stored for an HTTPS connection and required me to click OK to continue. This is great, but it does require users to read and understand what that means.
Safari, LastPass and Bitwarden all offered to fill without warning.
It surprised me that in 2021 there are still tools that think signing into services without HTTPS is OK, especially when they originally stored the password for an HTTPS site.
Test 2: Password managers vs. sites with a forged TLS certificate
The next test was to secure my phishing site with a TLS certificate, but not one signed by a certificate authority trusted by the browser.
Users would need to accept a scary warning from their web browser for this to be possible, but we learned a long time ago that an alarmingly high percentage won’t take the time to read the messages that warnings contain and just proceed with whatever it is they are doing.
Once again, Google Chrome and Microsoft Edge passed with flying colors, but the others fared more poorly. All the others either auto-filled the passwords as if nothing was wrong or happily filled them once I clicked inside of the password field on the imitation site.
While these behaviors are not technically vulnerabilities, I felt it was worth contacting the security teams of their respective organizations to ensure this was the intended behavior and inquire as to whether they would consider improving the behavior to provide a higher level of protection against MiTM attacks.
The Mozilla team agreed that the behavior for invalid certificates should match the behavior for HTTP login forms. We hope to see this change implemented in a future Firefox release.
1password’s Principal Security Architect, Jeffrey Goldberg, was receptive to my report and in fact helped me understand some of the limitations third-party password managers must deal with regarding browser APIs.
He explained that the current behavior was implemented before HTTPS was common and agreed to consider changes in future versions when faced with an apparent downgrade attack. Their hands are tied though when it comes to the fake certificates as only Firefox exposes an API allowing the password manager to tell if the certificate chain is invalid.
Apple product security responded to my report with:
After examining your report we do not see any actual security implications and is behaving correctly.
It is worth noting that as Safari v15 treats all HTTPS sites as if they have HSTS enabled, the risk here is mitigated, albeit in a non-compliant manner.
The Bitwarden team responded via HackerOne:
Hi. We have evaluated this report and plan to implement a solution for the HTTPS => HTTP downgrade attack scenario. For the second issue of using a self-signed certificate attack, browsers already implement sufficient means to block and warn users in this scenario, so we do not plan to implement anything additional.
LastPass also responded, via Bugcrowd. The important parts of their statement, abbreviated, are as follows:
When a user visits an HTTP site LastPass will allow the user to manually fill site credentials saved for that domain by clicking the LastPass fill icon in the login form, but LastPass will not autofill site credentials at page load automatically without user interaction. This behavior is by design.” After explaining the API issue, they continued “We will try to leverage this API in future releases of our Firefox extension, and we contacted the Google Chrome team asking them to prioritize implementing this API as well.
Lastly, Dashlane’s security team replied, which I have shortened for brevity:
When a webpage is reached using HTTP, we already have two security mechanisms implemented: The login without interaction is disabled, we require a user interaction (click on the web card). The web card shows a warning message if the user still wants to log in.
They also mentioned they would investigate the fake certificate situation and make a change,“if it’s available everywhere.” Considering it is only available on Firefox I assume this means no change.
The bottom line is that using a password manager is always better than not to ensure you have long, strong passwords. When they offer multi-factor authentication they are even better, and all the third parties do.
However, while the majority are resilient against HTTP downgrade attacks, there is still room for improvement. And when it comes to forged certificates, the burden is on you. Heed the warnings, don’t ignore them, and be especially suspicious when you are on networks you don’t trust.
Note: The Safari password manager test was performed in August 2021 using Safari version 14. Safari 15, which launched with Apple’s iOS 15 appears to now force HSTS to sites that do not advertise it. This may be a good thing but is far outside of the specification.
Disclaimer: Brand Desk Content