0

I manage a team of developers and only recently found out that passwords are not hashed at database level. We were trying to get PCI approved and the inspector informed me on the hush level that CC and Passwords are being stored by developers without hashes.

This made me concerned. Firstly, users automatically assume that SSL means their data is encrypted. This is not true since CC and Password information on our databases are stored in plain text (we have since removed this and have installed SALT on all data)

Is there a way for me on a website to see server side or find out if passwords and CC are actually encrypted.

2 Answers2

4

No, you can't be sure that a site has correctly hashed your password.

However, there can be some signs that they did not, particularly if they e-mail your existing password as part of the "forgot password" functionality.

Sjoerd
  • 30,589
  • 13
  • 80
  • 107
4

An end user can only hope their password is hashed, until the site is hacked and the passwords (or, hopefully, their salted and hashed versions) are leaked to the public.

As a manager, you have a few more options. You can ask where the passwords are stored, and verify that they are not stored in plaintext.
You could take this a step further and make it part of an automated test process - create a new user, with a randomized password. Verify that the new password does not show up in the database table that stores the user authentication data. You could even go further and test if the table you look at, really is the table used for user authentication - for example, by forcibly removing the user at the database level and trying to login again.

Automated systems, unfortunately, cannot give you a 100% guarantee that passwords aren't stored in plaintext somewhere in the code.
Human process is also prone to error and overlooking things. However, the combination of good automated tests and good human process (e.g. code reviews) should give you sufficient confidence that your user's data is protected properly. Or, if the worst comes to the worst, that you at least made a serious effort to protect the data.

As Khajak Vahanyan points out in the comments, SSL/TLS has nothing to do with it. SSL/TLS is about how the data is transported to the application, not about what happens to the data afterwards.

  • You could even go further and test if the table you look at, really is the table used for user authentication - for example, by forcibly removing the user at the database level and trying to login again. This was the key. As developers I have worked with before steal and take the user data to their next posts. +1 for that splendid! – TheBlackBenzKid Nov 15 '16 at 19:32