SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 66
  1. #26
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  2. #27
    An average geek earl-grey's Avatar
    Join Date
    Mar 2005
    Location
    Ukraine
    Posts
    1,403
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #28
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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. #29
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    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.

    Quote Originally Posted by Stormrider View Post
    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?

    Quote Originally Posted by Stormrider View Post
    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. #30
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TheRedDevil View Post
    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!

    Quote Originally Posted by TheRedDevil View Post
    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.

    Quote Originally Posted by TheRedDevil View Post
    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.

    Quote Originally Posted by TheRedDevil View Post
    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 . "%^Qrgtq3TQ4rner67agw%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. #31
    SitePoint Member
    Join Date
    Apr 2006
    Posts
    3
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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. #32
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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. #33
    SitePoint Member
    Join Date
    Apr 2006
    Posts
    3
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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. #34
    SitePoint Member
    Join Date
    Apr 2006
    Posts
    3
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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. #35
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #36
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    AlienDev, is it online?
    Quote Originally Posted by Stormrider View Post
    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.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  12. #37
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #38
    HAHA!
    Join Date
    Mar 2006
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Wardrop View Post
    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.
    Cheap web hosting directory listing the cheapest web hosting

    Submit articles to an article directory

  14. #39
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    To be honest, if someone has access to your administration / database - password encryption isn't going to be the biggest problem.

    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.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  15. #40
    SitePoint Enthusiast
    Join Date
    Dec 2004
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You should buy this book http://phpsecurity.org/

    double hashing is a waste of time.

  16. #41
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

    /* $password contains the password. */

    $salt = 'SHIFLETT';
    $password_hash = md5($salt . md5($password . $salt));

    /* Store password hash. */

    ?>

  17. #42
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. #43
    SitePoint Enthusiast
    Join Date
    Dec 2004
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    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. #44
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The method in book is:
    $password_hash = md5($salt . md5($password . $salt));
    Awfully like double hashing - applying md5 twice
    Or you were referring to the original md5(md5($password)) ?

  20. #45
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  21. #46
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Arkinstall, while keeping your transformations secret is considered good thing, relying on them to be secret is not.
    Kerckhoffs' principle
    Kerckhoffs' Requirements

  22. #47
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ckw View Post
    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. #48
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    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. #49
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    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. #50
    SitePoint Enthusiast
    Join Date
    Dec 2004
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    The method in book is:
    $password_hash = md5($salt . md5($password . $salt));
    Awfully like double hashing - applying md5 twice
    that's not double hashing. There's an extra layer there with the use of $salt.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •