April 21, 2016

Last Updated on January 16, 2024

View our free cybersecurity resources »

View Now!

Recently I did some onsite application penetration testing for a client where I noted in the report that their application did not tell the browser to turn off auto-completion of the user’s password. The OWASP guidance considers this an issue, and we’ve been flagging it as a minor vulnerability for as long as we’ve been doing application testing.
However, the client indicated to me that they’d read some information to the effect that modern browsers were starting to ignore it if autocomplete was turned off, and still offer to remember passwords anyway. The client, therefore, didn’t feel this was of concern.
Should flagging “autocomplete=on” as a vulnerability still considered a valid finding? I’ve done a bit of reading on it, and apparently a lot of browsers are starting to ignore if the website tells them not to save the user’s password, and offer to save it anyway.
There is still some arguments about whether or not that’s a good thing.
Personally, I think that autocomplete should be turned off if the website owner requests that it be turned off. But I can see the rationale that maybe it shouldn’t be a security finding anymore, and instead, simply be a decision that the website owner/maintainer makes.
Modern browsers store users’ passwords in various ways, but it’s not likely to have the security impact it once did when browsers often stored this data as clear text somewhere on the system. In that event, were the computer to be compromised the attacker could easily get a list of all the usernames and passwords the user had stored.
Fortunately, all modern browsers encrypt this data, so it’s much more difficult and time-consuming for hackers to retrieve. This largely mitigates the security risk of the browser storing the password.
Modern autocomplete functionality is also a bit smarter contextually than it used to be. Back in the day, anytime you visited a site and saved your username and password, the browser would try to use them again on the next site you visited if the field names matched. Modern browsers don’t auto-complete those fields unless the environment matches; that is, the same URL or at least the same domain.
So assuming autocomplete is turned on for a site, and someone launches a phishing attack that directs you to a bogus site, the fact that your browser doesn’t auto-complete the login could be a tip-off that something is wrong. That’s a dubious security benefit at best. But it illustrates why there are pros and cons to this issue.
Perhaps the strongest argument for “autocomplete=off” relates to public/kiosk computers at libraries or businesses. There’s a risk that, if a user absent-mindedly lets the browser save his or her password at one of these locations, it could be reused by someone else.
This could happen anywhere that multiple people might (legitimately or otherwise) access the same system. With shared systems, the security onus is on the system owner to configure it correctly so that installed browsers don’t ever ask to auto-complete user credentials. But a control at the application level is still beneficial in this scenario.
Whether you agree or disagree about “autocomplete = off,” in my opinion the fact that the default behavior of most browsers now is to ignore it if the website indicates that auto-completion should be turned off is something worth debating—especially as it relates to findings in application security testing.
Likewise, whether you agree or disagree, this issue points out the value of multi-factor authentication. In a 2FA scenario, even if stored login credentials are compromised they won’t be valid again anyhow. Setting users up with a password manager is another way to make their logins more secure under all conditions.
As a conductor of testing and a producer of reports, I’m going to continue to follow the published guidelines, which indicate that “autocomplete=off” should be in place. This will remain the policy for Pivot Point Security as a testing provider as well. But if a particular client wants to discuss the wording of the report with the penetration testing team, I’d be open to that.
To start a conversation on how expert, third-party penetration testing can help you validate the security of your applications, networks, and databases, contact Pivot Point Security.
For more information:

Don't Get Hooked!

Phishing emails are tricky. Based on our Cyber Security Awareness Taining material, the 10 Tips for Detecting Phishing Emails infographic provides a cheatsheet of what to look for in unfamiliar emails.
Download our Detecting Phishing Infographic now!

Download Now!