1

What if my server gets hacked and the hacker views my hashed passwords and can see what salt I was using.

Is it something to worry about?

R3dBu77
  • 39
  • 4

8 Answers8

2

It is not supposed to be a problem. The idea with salt values is that it prevents a rainbow attack (using precomputed values). So knowing the salt value does not expose a problem.

Mark Wilkins
  • 40,729
  • 5
  • 57
  • 110
  • Generating a salted rainbow table is not that difficult, so it *is* a problem. – deceze Dec 16 '10 at 03:13
  • 1
    @deceze: imho it is pointless to create rainbow tables for set of passwords salted with **different** salts, isn't it? – zerkms Dec 16 '10 at 03:14
  • Is there a way to protect the salt? – R3dBu77 Dec 16 '10 at 03:15
  • @zerkms I don't understand your assertion, can you elaborate? – deceze Dec 16 '10 at 03:15
  • @AZKyleP: you should not protect the salt specifically, but you should to protect your database from being downloaded ;-) – zerkms Dec 16 '10 at 03:16
  • @deceze: i meant - if each password salted with random 10chars string, then there is no reason to generate tables, why don't just bruteforce? – zerkms Dec 16 '10 at 03:17
  • @AZK Since *you* will need to work with the salt as well, no, not really. – deceze Dec 16 '10 at 03:17
  • @deceze: The idea of a rainbow table is that it is precomputed beforehand. The hacker pulls it off the shelf and uses it. If you compute a rainbow table based on given salt salt values ... well, it's not really a rainbow table. It's a brute force attack. If the salt is 20 bytes, you would need 2^160 rainbow tables (not feasible). If the hash uses a large number of iterations (e.g., PBKDF2 with 10,000 loops), then a brute force attack becomes extremely expensive. – Mark Wilkins Dec 16 '10 at 03:18
  • @zerkms Yes, *if* you're using one random salt per password the problem is raised to brute-force level complexity. If you're only using *one central* salt for all passwords, you can easily generate rainbow tables. Even if that takes a while, it only needs to be done once and then you've got *all* passwords. – deceze Dec 16 '10 at 03:18
  • 1
    @deceze a salt is random by definition; if you use '*one central salt*' you are not using a salt, you are using a key. As a result, you are longer computing a hash, but a Message Authentication Code (MAC). – Jacco Dec 16 '10 at 09:42
1

Yes it is. Now hacker can bruteforce them (if he knows how actually you salted the passwords).

Nothing more to worry - since you're using the salted passwords more intelligent attacks (other than bruteforce) cannot be applied.

zerkms
  • 249,484
  • 69
  • 436
  • 539
  • also to mention since the arrival of the mighty GPU and tools like oclhashcat cracking thousand of hashed password is easy. – RageZ Dec 16 '10 at 03:10
1

If the hacker has gotten into your system and has access to the database then its "game over" as far as your users privicy is concerned! The hacker has everything he wants except the users passwords which dont give anything he hasnt got already apart from the opperunity to spoof a user access --> which he can do very simply by putting his own hash and salt in the database!

So yes MD5 plus salt is "good enough" security in this case.

James Anderson
  • 27,109
  • 7
  • 50
  • 78
  • I agree. Unless data is spread across multiple servers, why do they need to even get the passwords when they can read the whole database anyway. – niggles Dec 16 '10 at 04:08
  • The point of making passwords as secure as possible is because people are using the same username and password on every site on the internet. Yes, if *your* server gets hacked it's game over for *you*. But you can at least prevent that that means game over for the user's account on *all other sites out there* by storing passwords in a truly non-reversible fashion! Of course, a user should take care of his own password security, but many simply don't. You don't want to become [Gawker](http://thenextweb.com/media/2010/12/13/gawker-hackers-release-file-with-ftp-author-reader-usernamespasswords/)! – deceze Dec 16 '10 at 06:55
0

To see the salt he must have the source code, and when he has it, there are at least some things to worry about - he will see the mechanism responsible of creating password and a way of salting them.

Tomasz Kowalczyk
  • 10,472
  • 6
  • 52
  • 68
0

Yes. He'd still need to reverse the hash, which isn't easy by any means, but now he knows a key part of the plaintext. The salt plus a dictionary attack is much more likely to succeed than snooping over the wire (with no knowledge of the salt) would be

Robert
  • 6,412
  • 3
  • 24
  • 26
0

Essentially the salt just makes the password stronger. It won't aid in the decryption of individual passwords if he has whatever your passwords are stored in and can run brute force attacks he can just figure out the salt when it ends up being the same in whatever passwords he decodes.

http://pbeblog.wordpress.com/2008/02/12/secure-hashes-in-php-using-salt/

This article has a pretty good explanation... so yes if the hacker can see your source code you should be worried but the salt alone isn't a big deal.

Randall Hunt
  • 12,132
  • 6
  • 32
  • 42
0

If you're using only one salt for all passwords, a hacker can pre-compute a salted rainbow table, which will give him access to all passwords rather quickly.

You can use a random salt for each individual password, which means a hacker would have to compute such a rainbow table for every salt, in effect brute-forcing every single password, which would slow him down quite significantly.

You can further slow him down by using a deliberately slow hash that will slow down brute-forcing to a point where it may become infeasible. MD5 is the worst choice because it's really fast (and broken to boot). The SHA family was also designed to be fast, but is a better choice. Bcrypt or generally the *fish family is decent, but support among systems and languages varies. Be careful to use a hash variant of *fish, since they are also used for encryption (can be reversed).

See http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/.

deceze
  • 510,633
  • 85
  • 743
  • 889
0

I am not an expert in this subject, but this is my understanding:

Given a salt, an attacker can build what's known as a "rainbow table", that's basically a reverse of the hash function. With this table, they can lookup an encrypted value in the table and get back an input password such that hash(password + salt) = encrypted value.

However, while lookups are quick, rainbow tables are very time consuming to build. A simple thing you can do is to generate a salt value randomly on a per-account basis and store it alongside the encrypted password. That way, if an attacker wanted to get passwords out, they would have to build a rainbow table for each user as opposed to building one site-wide.

(Having a salt is still much better than nothing because that way an attacker has to at least generate his own rainbow table as opposed to just downloading a stock one).

More information, and probably a better answer

Community
  • 1
  • 1
Jonathan
  • 2,043
  • 2
  • 13
  • 16