1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

login-system, PWD (+salt) check does not work, 2 different hashes

Discussion in 'PHP' started by iago111, Sep 12, 2020.

  1. #1
    Hello,

    I'm working on a PHP login-system based on an online tutorial. (I'm so close to finish this!!)
    I use the same functionality for creating a PWD and checkin it, and nonethless I have different hashes.

    I made a picture of the result that I receive:

    [​IMG]
    Salt for the check is the salt from the db, I also stored the non-encrypted PWD () in the database in oder to ckeck if theres is an error there, but no error (yellow line)
    Both hashes (black and red) do not match. The craetion of the salt cannot be a the reason for the probelm, obviously!!

    That's my check function:
     if($this->data()->password === Hash::make($password,$this->data()->salt)) {
    
                    echo 'OK';
    PHP:
    Perhaps the problem is the my Hash class, make method, I have no idea???

     class Hash {
    
            public static function make($string,$salt = '') {
    
                    return hash('sha256',$string.$salt);
    
            }
    
            public static function salt($length) {
    
                  return random_bytes($length);
            }
       
            public static function unique() {
    
                return self::make(uniqid());
            }
        }
    
    PHP:
    If somebody knows something here, thanks a lot!
     
    iago111, Sep 12, 2020 IP
  2. SpacePhoenix

    SpacePhoenix Well-Known Member

    Messages:
    196
    Likes Received:
    28
    Best Answers:
    2
    Trophy Points:
    155
    #2
    SpacePhoenix, Sep 12, 2020 IP
  3. Efetobor Agbontaen

    Efetobor Agbontaen Active Member

    Messages:
    136
    Likes Received:
    41
    Best Answers:
    5
    Trophy Points:
    85
    #3
    It would be easier if you just used the default hashing functions.

    For this that uses salts, you will have to store the salt you used in your table too. So to check, you have to re hash with the exact same salt. Using the exact same salt to hash the same string should give you the exact hashed string with the one you originally had.

    It might seem like you are defeating the purpose of salting by storing the salt but not at all.
     
    Efetobor Agbontaen, Sep 13, 2020 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #4
    Actually since salts are often stored in places hackers are as if not more likely to gain access to than the DB itself, salts more oft than not amount to nothing more than placebo BS.

    Putting it IN the database in the same huffing record? Whoever told the OP to do that?

    [​IMG]

    If you put it in the table, you have utterly, totally, and COMPLETELY defeated the point of even having a salt.

    As to the actual problem, the use of characters outside ASCII7 could be the problem, since Christmas only knows what the SQL engine and PHP are going to do with character encoding juggling!

    W base64 of some random_bytes would make a far better hash than this train wreck of characters that don't fit the ASCII7 character space! You go outside character codes 32..127, and f*** only knows what those random values could end up as when things like UTF-8 are in the mix. Whilst it may be a relic of 1960's computing mentality, the six-bit encoding of Base64 would likely avoid whatever problem is happening here.

    NOT that it's worth fixing since again, if the salt is in the same table as the hash, it serves ZERO legitimate purpose and whoever tells you to do it that way is flapping their arse-cheeks in the wind.

    Hence I'd axe that entire dipshit "Hash" class entirely.
     
    deathshadow, Sep 13, 2020 IP
  5. Efetobor Agbontaen

    Efetobor Agbontaen Active Member

    Messages:
    136
    Likes Received:
    41
    Best Answers:
    5
    Trophy Points:
    85
    #5
    Not completely sir. It makes cracking passwords harder. And it makes precomputation attacks like rainbow tables just plain useless.

    Though, I get your point of the idea being useless altogether. But consider that the idea of encryption in the first place is simply to make life harder for unauthorized users attempting to gain access.

    That said, I don't use salts at all
     
    Efetobor Agbontaen, Sep 13, 2020 IP
  6. iago111

    iago111 Member

    Messages:
    99
    Likes Received:
    4
    Best Answers:
    1
    Trophy Points:
    33
    #6
    Because I want to understand the whole concept of that login-system not every single part. (Just following rules, being a good German for the first time of my life)

    So that means that that a complex salt is not necessary at all. It is necessary to veil its identity /its location. But how can you not find the salt when you see how the password is regenerated at the end?
     
    iago111, Sep 15, 2020 IP
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #7
    And that's a good idea. It helps to understand a process before you go using an off the shelf answer. That's where frameworks screw over far too many people, is many dive for them before they even know enough about the underlying language to actually know if the framework is doing things right, or if every single statement about them are made in ignorance. (Tip, it's usually the latter.)

    For the most part. Hashes exist so if the table is compromised people can't just read the passwords, salting makes the hash harder to crack.. in theory... but in practice as computing power goes up, if the hash is right there next to the user in the same table, you're likely already far past worrying about password hash's being reversed.

    @Efetobor Agbontaen has it right in that hashes and salts are about making it harder. No system is bulletproof. But in practice you can overthink it without actually improving the security.

    Using a salt isn't a horrible idea, but storing it with the password is just silly. A single static salt used across the whole site would actually be as good in most cases. Perhaps even better as it means you can store the salt in the code, separate from the table. That way if your SQL gets hacked the passwords are useless without a code elevation or viewing source to extract the salt. This is even more true if you use good scope isolating practices, though with interpreted languages like PHP going full Gungan being able to read and display it's own source code that scope isolation can be equally meaningless.

    Seriously, it's scary -- and stupid -- how many PHP exploits would never have gotten as far as they did if PHP were simply unable to fopen, file_get_contents, or perform any other file operations on its own include files.

    Not sure what you even mean by that.

    I agree with you on not using password_verify, but for different reasons. It troubles me how many people dive for it when one of the earliest rules about database access I learned decades ago is to keep all password access mono-directional. You should NEVER write a query that reads and returns the password or a hash of same! To use password_verify you break this simple common sense rule.

    Hence my favored approach for a user login goes something like this.

    User creation:
    
    /* assumes $db is a connected PDO object */
    
    function db_create_user($db, $username, $password) {
    	$stmt = $db->prepare('
    		INSERT INTO users (
    			username, password
    		) VALUES (
    			?, ?
    		)
    	');
    	$stmt->execute([$username, hash('sha256', $password)]);
    	return $db->lastInsertId();
    } // db_create_user
    
    Code (markup):
    User login:
    
    function db_login_user($db, $username, $password) {
    	$stmt = $db->prepare('
    		SELECT id
    		FROM users
    		WHERE username = ?
    		AND password = ?
    	');
    	$stmt->execute([$username, hash('sha256', $password)]);
    	return ($id = $stmt->fetchColumn()) ? $id : -1;
    } // db_login_user
    
    Code (markup):
    I use -1 to indicate guest, which if a login returns guest, you know it failed. This is actually dumbed-down from a User class/object I use.

    That's really all there is to it, and there's oft little reason to get more complicated with it. At most if I were worried about security, I'd swap sha256 for either sha512 or whirlpool... and again use a global salt instead of trying to make a unique one in the DB.
     
    deathshadow, Sep 15, 2020 IP
  8. iago111

    iago111 Member

    Messages:
    99
    Likes Received:
    4
    Best Answers:
    1
    Trophy Points:
    33
    #8
    Ok, thanks, I check this part, in order not to spread myself too thin.. going on with that tutorial from that guy from Oxford, or was it Cambridge, or perhaps Oxford.
     
    Last edited: Sep 19, 2020
    iago111, Sep 19, 2020 IP