I have some sequential id which can be easily guessed. If some want to see data related to this id he has to prove his access by token I gave him before.
token = md5(secret_key + md5(id))
Is MD5 good enough for this job?
+2
A:
Don't use MD5. It is broken. I cannot believe VeriSign of all people still use MD5. There are test suites available for determining hash collisions for MD5 for use in breaking MD5 hash comparisons.
Use, at the absolute minimum, SHA-1. I recommend using SHA-5.
technically it's still secure if salted. However I still recommend SHA-1 or above myself now.
ewanm89
2009-09-10 16:57:51
Not if the salt is predictable. The md5(id) portion seems to be of little cryptographically value. Since the id can be easily guessed, so can it's md5 hash. If secret_key is either (relatively) sort or compromised, the solution is compromised.
Eric J.
2009-09-10 17:00:21
Salts are no less secure whether predictable or not, the idea of salts are if I get a download of the database tables that contains salts and hashes, so one needs exponentially larger rainbow tables to be able to break all the hashes. Also to make the hashes unique even if two people choose the same password. Predictable or not it does not matter.
ewanm89
2009-09-10 17:10:20
Assuming you want to crack with a rainbow table. Brute-force works for "short" original values (short being relative to your available time and computing power). The predictability of md5(id) means that it does not contribute significantly to the computational effort to find a brute-force solution.
Eric J.
2009-09-10 17:42:55
There is no SHA-5. NIST is currently holding a competition for selecting SHA-3.
Accipitridae
2009-09-30 19:10:51
+3
A:
It really depends on what you're trying to protect, but probably not. I don't see any reason not to use a stronger hashing function.
Bill the Lizard
2009-09-10 16:55:40
Storage space in this area is not really a problem, especially given just how cheap hard drives are now.
ewanm89
2009-09-10 17:11:55
Also, you can take a longer hash like SHA1, truncate it to 128 bits, and have equivalent-or-better security to MD5.
Nick Johnson
2009-09-11 07:31:20
+4
A:
Technically one does not even need to md5 the id before concatenation to be secure enough salting.
However I would generally suggest using sha-256 or sha-512 unless one has some serious performance concerns (say embedded programming).
ewanm89
2009-09-10 16:56:36
Not only does one not need to hash the id, it doesn't make any sense to hash the id. Hashing hashes does not create more security. Encrypting encryption is not more encrypted. I don't know where people get this idea, but it's insanity. The md5 hash value of 75 (or whatever else would be a representative sequential id) is just as easy to come by as the sequential id itself. Concatenate, then hash with a sha. Even better, use GUIDs instead which are practically impossible to guess.
Daniel Straight
2009-09-10 17:01:00
Actually, I've read that given a GUID, the next 250k GUIDs that a machine will generate can be predicted.
Thorarin
2009-09-10 17:03:22
Agreed, it can in certain situations actually decrease security, it however does actually mean that if someone is attacking they have to do at least an extra hash. As for GUIDs it depends on the situation and what you are hashing. Not all cases will have GUIDs available, at at the end of the day, it's just certain unique data that has already been hashed no different from hashed ID if ID is the primary key.
ewanm89
2009-09-10 17:05:01
@Thorarin: That was back when GUIDs were generated using a computer's MAC address, this hasnt been the case for some time now.
Neil N
2009-09-10 17:05:27
@Daniel Straight: the id is not under my control. So unless I store tabel with id to guid mapping I have to stick with id.
Jakub Šturc
2009-09-10 17:10:21
It is more important to pad the data out enough before hashing (this is where random salts come from).
ewanm89
2009-09-10 17:27:06
@Daniel Straight: You are wrong. Firstly, hashing and encryption are not the same. Secondly, the well respected HMAC algorithm does exactly what you claim is insane: it hashes twice. The resons for doing so are explained in the design paper of HMAC: much better security guarantees are possible by hashing twice.
Accipitridae
2009-09-11 06:35:47
+1
A:
If the ID can be easily guessed, this is not really very secure unless the secret key is quite long.
My PC can brute-force a secret_key value based on the MD5 in about a day for a secret_key of 6 characters. People with access to faster/more computers can greatly reduce that time. The time-to-break increases by a factor of 10 for each additional digit in the key. Since the ID can be easily guessed, and therefore it's MD5 value computed, it does not add much to the difficulty of reversing to get the secret_key.
Eric J.
2009-09-10 16:57:18
the ID is salting, it means that one can no longer just use rainbow tables to calculate the MD5s. As for brute forcing, you are still strongly overestimating how quick a PC can cycle through them.
ewanm89
2009-09-10 16:59:52
Salts do not need to remain secret, they just need to be unique for each record in the database.
ewanm89
2009-09-10 17:01:00
I'm not overestimating, that's experience. I have, in fact, reverse engineered lost PDF passwords by brute-forcing the md5 hash stored in the PDF file.
Eric J.
2009-09-10 17:40:17
+1
A:
I would recommend using an alternative solution, or (if not acceptable) adding more data to your md5 generation routine. If your secret_key is constant, and I am able to reverse engineer one hash, then I can generate the correct key for any other ID.
If you build something such as a random salt stored with your data plus the current time (if associated with the record you are protecting) into the md5 generation then it will dramatically increase the difficulty of the attack.
See:
Robert Venables
2009-09-10 17:00:55
You can store the randomly generated salt privately with the data you are protecting.
Robert Venables
2009-09-10 17:07:34
Actually I am not storing any data. I am only creating and interface to data which are not under my control.
Jakub Šturc
2009-09-10 17:13:18
@ewanm89: It looks like Jakub is simply regenerating the hash at runtime and then comparing it to the one that the user is supplying.
Robert Venables
2009-09-10 17:31:13
Okay, well then are we looking at use as a challenge-response authentication mechanism? If so there are many other problems anyway.
ewanm89
2009-09-10 21:40:16
+3
A:
Assuming that this is used for authentication I'd use HMAC. See for example FIPS PUB 198. This for example allows you to use a secure hash function (not MD5), truncate the result as described and still get secure tokens.
Accipitridae
2009-09-11 06:44:54