Salt passwords

    This note is intended to shed light on the use of salt when hashing a password. If you look in the comments on this topic habrahabr.ru/post/145642 , then there is a suspicion that some people misunderstand the purpose of salt. I will try to show by examples what this mechanism is used for. I ask everyone interested under cat.

    Imagine a simple authorization. A user gets a bunch of username / password values, we get a password hash and compare this bunch with the data stored in the database. For simplicity, we will use MD5 and PHP code examples.
           $password = md5($password);
    

    In this case, if the user has the qwerty password , we will get the following hash: d8578edf8458ce06fbc5bb76a58c5ca4 . If an attacker gains access to our database, he can take advantage of ready-made services ( http://wordd.org/D8578EDF8458CE06FBC5BB76A58C5CA4 ) in which he already has values ​​that give this hash, or he can remove it himself.
    To protect against already prepared hash tables with values, you can use a static salt:
           $password = md5($password . "MyUniqueSault");
    

    Now with the same qwerty password, we get a completely different hash bdadb0330124cda0e8499c9cd118f7bd . Ready-made tables will no longer help the attacker, he will have to use brute force. This is where the minus of static salt lies: an attacker will be able to generate his hash table with a static salt and get the values ​​of most passwords from the database. To eliminate this minus, a unique salt is used for each hash:
           $sault = GenerateRandomString();
           $password = md5($password . $sault);
    

    Those. now in addition to the login / password hash, the database will need to store the value of the generated salt for each user. Let's analyze an example: we have two users: user1 and user2. Both use the qwerty password . But in the first, zxcv salt was generated, and in the second asdf . As a result, users with the same password will have different hashes: 1d8f3272b013387bbebcbedb4758586d and a192862aa3bf46dffb57b12bdcc4c199What this gives: now it will not be possible to generate one hash table; to find the value of the hash with the dynamic salt, it will have to be regenerated. All this is aimed at increasing the time of selecting values ​​in the event of a "drain" of the database, using "good" hashing algorithms, it can already take a significant amount of time to select at least a couple of passwords. It is important to understand that the generated salt protects not one single user, but all together from the mass brutus. That's all, I want to remind you that use cryptographic hash algorithms SHA1, SHA512. The MD5 used above is not recommended for use, as recognized obsolete.


    Kolonist summarized well in his comment habrahabr.ru/post/145648/#comment_4894759 (for which he thanks a lot and plus):
    Once again.

    1. No salt - use ready-made rainbow tables.
    2. There is one salt on all - we generate one rainbow table and “break” all users on it.
    3. There is a separate salt for each user - separately brute force for each user.

    Also popular now: