## User Tag List

1. Multiple Encryption without salts on each stage are weaker for reasons I explained earlier.

With salts? I don't think there is any reason not to use them - they don't put much more processing weight on the server, and they are more secure.

2. It is somewhat harder to prove that multiple applications of common hashing algorithms make system less secure, as it needs particular algorithm analysis, since it's not true in a generic case.

But it's relatively easy to show that it doesn't make it more secure, regardless of the algorithm, in math language.

Let's say we deal with m-bit characters and k-bit hashing algorithm. At first, we need to map a character string to number. It can be done like:
Code:
`n = s[0] * ((2 ^ m) ^ 0) + s[1] * ((2 ^ m) ^ 1) + ... + s[n - 1] * ((2 ^ m) ^ (n - 1))`
Then we describe a hashing algorithm as a function: y = f(x), where x ≥ 0.

If we had applied the hashing function once, the range of values we can get is: y1 ∈ [0; 2 ^ k - 1] => |y1| = 2 ^ k.

After next function application, we can get, at most, the same range of values, as we use the same function: y2 ∈ [0; 2 ^ k - 1] => |y2| ≤ 2 ^ k. (The equality -- the best case -- happens if our discrete function is invertible -- there are no two x values in range [0; 2 ^ k - 1], for which f(x) has the same value. And, in that сase, double application of function is not more, not less secure than single.)

From the above we have that |f(f(x))| ≤ |f(x)|. And, using induction (by substitution of x with f(x) on the left side), we get that n'th application of f has power less than or equal to that of f(x).

3. Yes. While theoretically it is true, the fact is that many rainbow tables exist for single pass md5 hashing, whereas not so many exist for multiple iterations (I imagine less as you go on) so in reality / practically, multiple iterations will be slightly more secure in a real world situation, even if not actually mathematically more secure.

4. Originally Posted by Stormrider
This is wrong - even if the person has the salt, it is far more secure than not using a salt at all. The reason being that they don't know how that salt is used (before the password? after it? somewhere in between more complicated strings? etc), and then even if you do, you have to generate all the rainbow tables for that specific hashing + salt method, which takes a very long time. You would have to do this for every user whose password you want to crack.
Yes, your correct. But if this was a public available script, either free or by a purchase of a license you would have access to how the hash is applied by default. No one will try to break hashed passwords unless they know how it is created, as it would be close to impossible and would require a lot more processing power. Note. I am thinking on properly created hashes, we all know it is a relativ fast process to create a rainbow table on for example md5 hashes under 50 characters long compared to create one with md5 hashes up to 200 characters.

You are also correct that its impossible to store the failed results into a rainbow table when you also use a public salt (well its possible, but the chance for it beeing efficient is much smaller). But if you have the process behind how the hash is created it is much easier to brute force it when only a public salt is used compared to if you use both a public and a hidden.

For my initial reply that you quoted, I was thinking in regards to that specific piece of code, which was why I mentioned it. Though as you mention, we have an adventage as we have seen the code; but in most cases that is always the case before someone try to brute force hashes.

Originally Posted by Stormrider
I don't think having 2 hashes makes it any more vulnerable really. In fact, it makes it more secure. Even if you have the 2 hashes, you STILL don't know:
- Which hashing method(s) or combinations were used in each
- The server salt in each
- How the user salt is used in each

Without any of this information, it would be pretty much impossible to crack anything. WITH this information, you would then have to generate 2 sets of rainbow tables, one for each hashing method, and THEN cross reference them to make sure you have got their password, not just something that clashes when hashed.

There is no reason why one hashing method should be any weaker than the others, and even if it was - it is still going to be far more secure than using that hashing method on its own, there is an extra layer of security (the 2nd hash) on this one.
I am sorry, English is not my first language and sometimes what I type is not exactly what I meant to say.

Weaker was not the correct word for what I was trying to say, as we are talking about hashes not encryptions. What I tried to say was, that the different hashing methods will have different loads when run. I.e. it is faster to run a sha256 hash than a sha512 hash. So in the event you have two different hash types you would first try to brute force the hash which required "less resources to run".

I am starting to like the idea with two different hashes, and if you alter the way the salt is appended etc it is much stronger. I wrongly assumed that you would use the same method on both, not sure why I did; but that was the case.

Are you storing them in two different columns or do you store them in one column and then just split them before comparing?

Originally Posted by Stormrider
Yes. While theoretically it is true, the fact is that many rainbow tables exist for single pass md5 hashing, whereas not so many exist for multiple iterations (I imagine less as you go on) so in reality / practically, multiple iterations will be slightly more secure in a real world situation, even if not actually mathematically more secure.
I thought we agreed that rainbow tables were not really an issue with a good salt?

Personally I am not worried or scared by the fact that there exist many rainbow tables, Ive tried multiple of them (the largest over 100 GB in size) and Ive not had any other hashes break other than what I would call weak password/salt solutions.

5. Originally Posted by TheRedDevil
I am sorry, English is not my first language and sometimes what I type is not exactly what I meant to say.
You are doing pretty well from where I was sitting - I didn't guess you weren't english!

Originally Posted by TheRedDevil
Weaker was not the correct word for what I was trying to say, as we are talking about hashes not encryptions. What I tried to say was, that the different hashing methods will have different loads when run. I.e. it is faster to run a sha256 hash than a sha512 hash. So in the event you have two different hash types you would first try to brute force the hash which required "less resources to run".
Yes, but imagine if your site only had the 1 hash, the one that is faster to run. You'd still be happy with the security on it as long as you used a good salt, so adding the other one adds that extra layer of security, and doesn't take anything away. The main purpose of it is to stop clashes - a rainbow table could come up with something that is quite short but hashes to the same thing using your hashing method, this reduces the risk of that.

Originally Posted by TheRedDevil
I am starting to like the idea with two different hashes, and if you alter the way the salt is appended etc it is much stronger. I wrongly assumed that you would use the same method on both, not sure why I did; but that was the case.

Are you storing them in two different columns or do you store them in one column and then just split them before comparing?
2 separate columns, but I don't think it makes that much of a difference how you do it really.

Originally Posted by TheRedDevil
I thought we agreed that rainbow tables were not really an issue with a good salt?

Personally I am not worried or scared by the fact that there exist many rainbow tables, Ive tried multiple of them (the largest over 100 GB in size) and Ive not had any other hashes break other than what I would call weak password/salt solutions.
Yes, I agree, it isn't an issue with a salt. However, I was trying to answer the original question of is md5(md5()) better than just md5(), and I think it is slightly stronger, in a real world situation. However, nothing beats using a good salt (or 2!) applied properly.

Generally, one of my hashing methods follows this kind of format (although I have made this up on the spot, not copied it from one of my projects, ha!):

Code:
`\$strHash = sha1(\$strPassword . "%^Q£rgtq3TQ4rner67agw£%NWR&^q253A357a23%FCqw6bawj46...you-get-the-idea" . strrev(md5(\$strPassword . \$strUserSalt . "GAE6jhawe4^Aw4she45^GSD&" . strrev(\$strPassword))) . "zsw4gawn6SZERYas46" . strrev(\$strUserSalt) . "taW£%Fawe6nxfgt&*HDrt7hs" . \$strPassword);`
Basically a complete mess of hashes within hashes, salts, the user salt a couple of times, the password you want to hash, the reverse of that password, reverse of the user salt... all combined in one big hashing method. Noone is going to guess how it is done unless they break onto the server, but then they still have the task of generating rainbow tables for every single user separately, because of the user salt.

Have another method that is something similar, store both and compare both, and you are sorted!

6. Whats everyones thoughts on this?.

don't hash but encrypt

assume a key lives on server

a new user signs up and submits their new pwd
append password to key, encrypt pwd and store
like...

\$key = "abc...";
\$newKey = \$key . \$_POST['pwd'];
\$crypt = new Crypt(\$newKey);
\$encrypted = \$crypt->encrypt(\$_POST['pwd']);
store \$encrypted in db

When the user tries to log in do the same but decrypt instead - if decrypted matches submitted pwd then they're authenticated

- this way, the encrypted passwords are not crackable with rainbow tables
- if stolen on their own, the encrypted passwords are very secure
- if the encrypted pwds are stolen along with the key, they are still very secure
- if they are stolen with the key and the code that shows the proecess, it would take a brute force attack to crack a pwd - my understanding is that a brute force of that nature would take too long

7. That is effectively a hashing method though, and rainbow tables can easily be generated for it - although a lot of effort, it is entirely wrong to say they aren't crackable with rainbow tables.

I'd rather trust one of the established hashing methods like sha1, which have had a lot of research done into them and are fairly secure, rather than a hashing method I made myself when I have no idea about the security of it.

8. My understanding of rainbow tables is that they work on something like md5 because the hash is always the same for the given input. In this case, the encrypted output that gets stored is not the same each time the input goes through the encryption process.

9. I'd rather trust one of the established hashing methods like sha1, which have had a lot of research done into them and are fairly secure, rather than a hashing method I made myself when I have no idea about the security of it.
Just to clarify, I generally use Blowfish - so it's not something I made myself and I do know it is secure.

10. The first paper I mentioned comes to conclusion that you can use encryption algorithm for this.
The reason for doing such an resource intensive password expansion is to slow down dictionary attacks, as you can see for expansion that uses N iterations it is slowed down exactly N times (provided that hash function used or encryption algorithm used are with desired cryptographic properties) as compared with one iteration case.

If we look at graph of simple hash function H(x), that has codomain={A..L}
We see that H(H(H(H(A))))=E.

Now the problem with simple multiple hashing is that overall structure for given hash function remains constant. That way it is feasible to maintain dictionary tables for multiple iterations of this hash function. The picture changes a lot if we add fixed salt=s in every iteration (shown with green arrows):

Because of fact that while A is member of subdomain domB, for witch H(domB)=B, the string A+s is not necessarily a member of this subdomain. So effectively the graph for H(X+s) where s is salt looks like this:

The good thing is that we can expect this sequence to change with every different salt value. The bad thing is that nobody has really investigated, how pretty these graphs form in reality.

11. Originally Posted by Aleksejs
AlienDev, is it online?
Originally Posted by Stormrider
AlienDev: I'd also love to look at the reasoning. Any other place that explains it all?
Its a 'real' book; sorry not online. Only place I've read that explains it well.

12. AlienDev, ok, will try to get that book one way or another. Any comments on how it contradicts the paper I was refering to?

13. Originally Posted by Wardrop
I just got the idea of double hashing stored passwords. In theory, this would make it a lot more difficult for someone to crack a password using brute-force. One would need to know first of all that the password is double hashed (if they didn't know that, then they've got no chance of brute-forcing the password). If they knew it was double hashed, then it would take their brute-force engine twice as long to crack the password as the engine would need to run the md5 algorithm twice.

If you still haven't caught on, by double hashing I mean...

PHP Code:
``` \$hash = MD5(MD5(\$password));  ```
Is doing something like this a good measure to further protect a users password?
ophcrack and rainbow tables will take care of that password very quickly and effortlessly. What you need to make people's lives more difficult is salt as was mentioned before. The hacker then needs to find the salt and calculate rainbow tables based on that which may take quite a while. What is often overlooked however is that in most cases cracking passwords isn't necessary for intrusion at all. Many security holes allow attackers to roam around freely and happily in your system without ever bothering with your password at all.

There are many way to create a practically unbreakable encryption. Especially if they don't know your method, e.g:
PHP Code:
``` \$password = 'Password123'; \$salt = 'fni021f'; echo MD5(~MD5(\$password) . \$salt . MD5(~\$password . ~\$salt));  ```
Unexpected bitwise operators can be a godsend when it comes to encryption.

15. You should buy this book http://phpsecurity.org/

double hashing is a waste of time.

16. Chris9902, can you please point where exactly this book says that "double hashing is a waste of time"?
According to one that I have - Appendix C.1 Storing passwords:
You should never store cleartext passwords in a database. Instead, store the hash of the password, and use a salt for best results:

<?php

\$salt = 'SHIFLETT';

?>

17. AlienDev, Ok I got the book, so which part are you referring to? I found on page 117 in chapter named "Secrets-Making and breaking a code" a subtitle - "What makes your password safe", I read it, but all it said was what a hash function is, what properties should it have to be cryptographically secure hash function and latest developments (to the date of book publishing) of cryptanalysis of MD5 and SHA1. Nothing about double hashing at all.

18. Originally Posted by Aleksejs
Chris9902, can you please point where exactly this book says that "double hashing is a waste of time"?
It doesn't. That was my comment.

The book (as you've already posted) shows you how to handle encryption. There's no need to double hash if you use the method you posted (from the book). Using a salt and md5() or sha1() is plenty good. Double hashing only adds work for the CPU (so it's a waste of time).

19. The method in book is:
Awfully like double hashing - applying md5 twice
Or you were referring to the original md5(md5(\$password)) ?

20. I think he was refering to the original.

Multiple MD5ing without salts are, as I said, weaker. Why weaker? Because it allows for more collisions - The more collisions, the weaker the hash.

But if you run the password through a few bit-wise operations, you will find that even if they DID break it, they'd need to know what you did to it to get a password that's not a load of garbage.

21. Arkinstall, while keeping your transformations secret is considered good thing, relying on them to be secret is not.
Kerckhoffs' principle
Kerckhoffs' Requirements

22. Originally Posted by ckw
My understanding of rainbow tables is that they work on something like md5 because the hash is always the same for the given input. In this case, the encrypted output that gets stored is not the same each time the input goes through the encryption process.
No, it is still the same for the given input. Otherwise, it would be pretty useless as you'd never be able to check the password against anything!

The key changes with each different input here, but you will still always get the same output for the same input. Therefore, rainbow tables can be generated just as easily.

23. Originally Posted by Aleksejs
Arkinstall, while keeping your transformations secret is considered good thing, relying on them to be secret is not.
Kerckhoffs' principle
Kerckhoffs' Requirements
Exactly - its a principle of cryptography that it should rely on the key being kept secret, not the algorithm / encryption process. Although with hashes this is slightly irrelevant because there isn't really a key as such. In this case, its the length of time it would take to break passwords given a hash and the algorithm that is the key factor.

24. Originally Posted by arkinstall
Multiple MD5ing without salts are, as I said, weaker. Why weaker? Because it allows for more collisions - The more collisions, the weaker the hash.
This is definitely rubbish. Using a salt has nothing to do with reducing collisions at all - you are just as likely to get a collision using a salt as without. The point of it is to 'personalise' the hashing function as such, so rainbow tables won't exist for your particular hashing method, and would be a lengthy process to generate.

25. Originally Posted by Aleksejs
The method in book is:
Awfully like double hashing - applying md5 twice
that's not double hashing. There's an extra layer there with the use of \$salt.