After every breach hits the news, I, along with everyone else, receive the dreaded email asking me to reset my password. The email told me that my leaked password was 'encrypted' but gave no more details than that. Despite the fact that I can't think of any reason my password should be encrypted, and not hashed, companies resist attempts to garner more information about the statement and also come into the firing line for other shortcomings around their use of passwords. All of this has made me wonder whether sites should inform users about how they store their passwords as a general rule.


The Ebay Hack

When it hit the news a couple of years ago that eBay had suffered a breach, I immediately made my way over to their site and started the password reset procedure. At some point in February or March 2014 it seems that someone gained unauthorised access to a database that contained 'encrypted passwords' and other 'non-financial data' on as many as 145 million eBay users. Details around how the breach occurred and who may have been responsible were thin and eBay faced increasing backlash over their poor handling of the situation. Without any details on exactly how my password was being stored, and little information emerging from eBay, I was left wondering whether or not I should already know how my password was being stored.

eBay


Disclosing Password Storage Policies

My initial thought was that sites should have a simple statement somewhere that lets users know how passwords are stored. It doesn't need a lot of technical information and is something a developer could provide quite easily. Knowing what hashing process is used, how many iterations and what kind of salts they use is all information that would help you assess how seriously a site takes the secure storage of your credentials. A brief paragraph in the privacy policy seems like it would be the most ideal place to keep such information. When I got to talking about this with other members of the community, it sparked some quite spirited discussions and brought to light a lot of interesting points.

FAQ


Assisting An Attacker

The most common point raised against my suggestion of open disclosure was that such information could assist an attacker. Whilst I can kind of see the argument here, I don't think it stands up to much scrutiny. For starters, if the passwords were hashed properly with an effective salt, the cost of recovery of even a single password should start to make an attacker think twice about trying to brute force the hashes. Faced with a reasonable password policy, say 10k rounds of PBKDF2 and a 128-bit salt, is an attacker going to have a realistic hope of breaking hashes fast enough to be worthwhile? The attacker knows exactly what they need to do, but that doesn't reduce the computational burden of actually doing it. Not to mention the fact that they actually have to compromise the site before this information is even useful! It should be the computational expense that protects the passwords, not obscurity surrounding the chosen method of hashing. To counter the worries of disclosing this information, Kerckhoffs's Principle was thrown into the mix. Specifically, Kerckchoffs's second principle seems particularly relevant and states:


It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;

In the context of our password hashing disclosure, this basically means that even if an attacker knows every detail about how we store our passwords, it shouldn't assist them in breaking the hash. This is exactly the case if we do it properly.


What About The Average User?

Another frequent point that was brought up was the implications for the average user. The average user that uses the same password across all sites doesn't really have a care in the world about password storage mechanisms. This is just going to be confusing and irrelevant information to them, and I'd agree. This information should be available to those who want to know. No one really reads those big long privacy policies anyway, but if you want to know how a site stores your password, a quick search on the page will turn up the information you need. This gives those of us who want to know the ability to find out, and those of us who don't care can carry on blissfully unaware. We don't need more useless badges littered across websites


What Is The Benefit?

To me, there is one main benefit. It allows us to have confidence in the capabilities of a site. Members of the security community can review the information and companies can be called out on poor password storage. If you found md5($password.$salt) in the policy of your favorite online retailer, would you not be inclined to contact them? We've seen, on many occasions, the impact that a single tweet can have on corporate security policies once it gains traction. Would it not be better if there was transparency around these things from the start? Responsible disclosure programs are popping up all over the internet so there is clearly a dedicated community of security professionals that are prepared and willing to work towards a more secure Internet. Besides, finding out that our passwords were stored as a salted md5 hash after they have been leaked is no use to anyone. With greater transparency these issues can be fixed before your database table ends up on Pastebin.


Users Should Do Passwords Right!

This may strike you as odd, but it was quite an interesting point. The 2 distinct reasons that came up as a requirement to password hashing were to prevent an attacker from logging in to the host site while they detect and resolve a breach, and to stop an attacker from breaking the passwords to try on other sites for password re-use. The first point should hopefully be a shorter term objective. We'd hope and expect that a site would be able to detect such an intrusion and resolve it in time to reset users passwords before they were cracked. The second point is a more long term objective. The password hash needs to stand up to enough brute force effort that it can withstand being cracked within a reasonable amount of time and an attacker will give up, or allow users enough time to reset passwords elsewhere. Both of these concerns can be almost completely removed with good password behavior from users. If passwords were unique across services and had 100 bits of entropy, 10k rounds of PBKDF2 would be a huge amount of overkill. A few rounds of SHA1 would probably do with a basic salt. So it seems the point really was that, if users did passwords right, we wouldn't need all this hassle of insanely secure password storage. Whilst I don't disagree with what's being said from a technical perspective, I think that it's unrealistic that we will ever be at a point where we don't need to protect some users from themselves, so we will always need to operate on a worst case scenario. When we store user credentials, we don't need to protect them just so an attacker can't login to our service, it's all the other services an attacker could use them to login to also. When we consider the prevalence of poor passwords and password reuse, I don't think we will ever get to this stage. Hashing passwords properly is fairly easy, and cloud compute power is cheap enough to come by in reasonable quantities, so I don't think we should offload this responsibility to the user.


What are the risks?

Personally, I can't think of any risks to disclosing how you store passwords. Especially not if you're storing passwords properly. Of course, as a user of a site, we have only their word that they are actually doing what they say they're doing and haven't just typed up something fancy to appease the masses. We're at risk of being given misleading information, much like little padlock icons or 'secure' messages on login screens that ultimately promise everything and deliver nothing.


In Closing

I think that sites should certainly be open about how they store this information. If having this kind of information posted online somewhere is deemed to be too much, then perhaps the password storage policies of the site in question aren't up to scratch. I'd like to see greater transparency from hosts about how they store this information, but what do you think? In the spirit of practising what I preach, the password storage policies of https://report-uri.io are linked to on pages where you insert your password and are available in the FAQ. As the requirements of password storage change I will keep the information up to date and always be happy to openly talk about and listen to constructive criticism of my methods. This is the only way that we can ensure we stay ahead of the game to protect our users to the best of our ability. If someone tells you that they can't disclose their password storage methods 'for security reasons', point them back here!