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.

TheBlackBenzKid
  • 103
  • 3
  • Are you asking if you're a regular user of a website, a way to find out how they store passwords and credit card details? – Ryan Kelso Nov 15 '16 at 12:23
  • 2
    This happens on the application level. The communication protocols have no way of confirming/hinting about it. – Khajak Vahanyan Nov 15 '16 at 12:23
  • 1
    The answer to this is "No, you can't" (other than cases where a known software is uses where you can download a copy and look into the source) – deviantfan Nov 15 '16 at 12:24
  • btw, it's really weird that at this age, there are applications that store password in plain text – Khajak Vahanyan Nov 15 '16 at 12:25
  • @KhajakVahanyan It's sad, yes, but weird? You'd be surprised how many lazy stupid people don't want to hear about hashes, sql injections or similar things, because it requries them to write some more lines of code. – deviantfan Nov 15 '16 at 12:29
  • @deviantfan, as a lazy web dev, I use some framework to not worry about that and other common stuff. – Khajak Vahanyan Nov 15 '16 at 12:31
  • 6
    Possible duplicate of [How to tell if a site is securely storing passwords?](http://security.stackexchange.com/questions/44802/how-to-tell-if-a-site-is-securely-storing-passwords) – Sjoerd Nov 15 '16 at 12:37
  • @KhajakVahanyan "lazy stupid", not just "lazy" :) There are plenty hired PHP "developers" around that are unable to concatenate two variables. This kind won't suddenly start using ORM etc. – deviantfan Nov 15 '16 at 12:49
  • 1
    It's not a duplicate. The other question asks if the end user can know this. This question asks if you can know it when you have legitimate access to the server. – S.L. Barth Nov 15 '16 at 13:34

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
  • 28,897
  • 12
  • 76
  • 102
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.

Community
  • 1
S.L. Barth
  • 5,504
  • 8
  • 39
  • 47
  • `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