12

My basic knowledge would assume yes, unless websites somehow include the user name into the hashing function with the password, but I am not sure if this is common practice.

Just
  • 121
  • 1
  • 3
  • 7
    Not unless the site has been dangerously negligent with their security and doesn't use random salts. In which case you have bigger problems. – Shadur Feb 25 '16 at 10:51
  • 4
    Related: [Why are salted hashes more secure for password storage?](http://security.stackexchange.com/q/51959/29865) – Ajedi32 Feb 25 '16 at 14:40
  • 1
    I agree with the duplicate suggestion. However, let me write a bit to connect the two. It is highly unlikely that all sites will have picked the same hashing function, and use the exact same implementation of the hashing function (as it says, developers love reinventing the wheel). Even if they use the exact same implementation, a *salt* is by nature a random piece of information. This randomness ensures that all hashes should be different across sites. – Ohnana Feb 25 '16 at 14:42

2 Answers2

25

It depends on whether or not they add individual salts or if they use a common salt (or no salt at all).

If they use individual salts, then they'll be different; otherwise, they'll [likely] be the same.

iAdjunct
  • 1,710
  • 10
  • 15
  • I guess what I was wondering was is this practice industry standard? – Just Feb 25 '16 at 03:47
  • 18
    It should be, and it is if you ask anyone that knows what they're talking about. But the sad truth is that many websites don't follow that 'standard'... making it less of a standard and more of a "ow god I hope people do this" – Nanne Feb 25 '16 at 08:25
  • @Nanne I think you should clarify what you are relating to when you are talking about what is common practice. OP may be confused as to whether you are referring to this answer or his question. In my experience common practice is to "Salt" your passwords with unique salts (e.g. users email address) this way each users password hash is different and unique – User1 Feb 25 '16 at 09:26
  • 4
    I was trying to say that words like "industry standard" and "common practice" are hard. It is "best practice" to do a salt but the sad fact is that it is not per se the most used practice because there is a lot of sh*t out there. So there, maybe my english isn't very good but I was trying to imply that although something is a 'standard', this does not mean it is done this way. In any case, my response was a response to the comment asking if salting is an industry standard – Nanne Feb 25 '16 at 09:45
12

As always, a good read is Thomas Pornin's canonical answer to How to securely hash passwords, which gives both advice and explanations on unique per-user cryptographically random salts, with PBKDF2, BCrypt, and SCrypt being algorithms of choice and said salts being mandatory.

For your particular question, simply read through the security.stackexchange.com and stackoverflow.com questions with the "passwords" tag, and you will quickly find that there is NO standard way of doing anything with passwords.

SCrypt is nearly unknown.

BCrypt is mostly reserved for PHP 5.5 and up (and 5.3.7 with password_compat; there's a good number of PHP folks using it, and a good number of PHP folks using something else.

PBKDF2 is the good choice for nearly everyone else.

And you STILL have a combination of other iterated hash methods (often with salting mistakes), single iterations of a hash (usually with salting mistakes), unsalted hashes, and out and out Don't be a Dave questions, over and over and over and over and over again.

So no; when it comes to actually dealing with passwords, you should assume that Dave is coding your website.

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • For PHP, Bcrypt is encouraged over Scrypt (http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html). And if people are using PHP, they really should be using at least 5.5 anyway. There's really no reason to be that behind. For Ruby on Rails, Bcrypt seems to be the favorite. And the nice thing about Bcrypt is it does the salt automatically. – h4ckNinja Feb 25 '16 at 05:49
  • 1
    BCrypt is also standard with Spring Security (Java): http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCryptPasswordEncoder.html – Wim Deblauwe Feb 25 '16 at 07:24
  • @Micheal - as of this month, there's at least one hosting provider only supporting 5.3.3. I've seen several PHP questions regarding passwords where they weren't even on 5.3.7, so not even password_compat was allowed. I agree they SHOULD be on something but newer, but the depressing fact is they are not. – Anti-weakpasswords Feb 25 '16 at 23:31