One of the most basic things you learn as you begin developing software that handle user accounts and passwords, is the importance of storing their passwords securely. Storing passwords securely is done by storing the result of a one-way cryptographic function instead of storing the password in plain text in the user database. Which cryptographic function you as a developer should use is always an ongoing discussion that changes often.
A few years ago, MD5 was recommended by many, then SHA-1 after MD5 was known to have collision vulnerabilities. While SHA-1 also has known vulnerabilities, some argue that the real problem with storing passwords hashed with MD5 or SHA-1 is not due to their cryptographic flaws, but rather the fact that hashes are too easily computed, meaning that it is possible to compute and test billions of password hashes per second. Today, many still use hash functions like MD5 and SHA-1 for storing passwords, but OWASP among others currently recommends using PBKDF2 or scrypt and include salts.
The reason we absolutely do not want to store passwords in plain text is quite simple: If (or when) an attacker gains access to the user database, the attacker not only has full access to log into any account on the system, but he is also able to try the passwords he found to log into other accounts on other systems. The RockYou breach is a famous example of a serious user database breach, where 32 million user accounts and their corresponding plain text passwords were stolen by an attacker.
In 2013, it should be clear for most developers that storing passwords in plain text is not a good idea. Still, many websites seem to neglect the consequences of insecure storage. One method that may indicate whether or not a website stores the password in plain text, is by simply using their “forgotten password” function. If this returns your original password in plain text via email, your password is not stored securely. Plaintextoffenders.com is a site that regularly posts screenshots of this happening, with the purpose of shaming those who are guilty of storing their users’ passwords insecurely.
After receiving my password in plain text from a large website that should have known better, I decided to take a little look at how widespread insecure user password storage is among Norwegian webshops. I picked 100 Norwegian webshops semi-randomly, created an account on each site and used their “forgotten password” function to see what I got back. The following table shows the result of the study:
[easytable]
Category, Total number of sites, Number of sites storing in plain text, Percentage plain text in category
Auction, 2, 1, 50%
Books, 5, 3, 60%
Classified ads & jobs, 3, 3, 100%
Clothes & shoes, 22, 7, 31.81%
Electronics, 29, 3, 10.34%
Health, 9, 4, 44.44%
Home & indoors, 7, 0, 0%
Software, 3, 1, 33.33%
Outdoors & sports, 16, 2, 12.5%
Tickets, 4, 1, 25%
Sum[attr style=”font-weight:bold”], 100[attr style=”font-weight:bold”], 25[attr style=”font-weight:bold”], Total plain text: 25%[attr style=”font-weight:bold”]
[/easytable]
As the table shows, 25% of the examined webshops store their users’ passwords in plain text. Among these were several quite popular shops most likely with many customers. Some of the webshops had functionality that made it possible to both save the payment card used and change the recipient. In other words: An attacker gaining access to the user database is able to log into any account of the website and order products to any address he wants, using another person’s payment card of this information is stored.
When ordering products from webshops, customers must be able to trust that the businesses handle their credentials and personal data securely. Based on this short little study, it seems that not all webshops are trustworthy in terms of user data protection. The few times I have tried contacting the webshops to ask why they don’t store my password securely, I have not received any answers. Perhaps they take action if more people notify them? Let’s just hope they don’t learn the potential consequences the hard way.