Secure login & register system with hashed passwords
So I have a table where I store user info like hashed passwords, emails, names etc. And I face this problem. When 2 users have the same password one of them can access other’s account knowing their email. What solutions could you suggest? Thank you.
Here is how i try:
<?php $pscoo = $_COOKIE['sw12Hj0i6y']; $dthshcoo = $_COOKIE['dthsh']; $pass = $_POST['pass']; // i get this from other page $mail = $_POST['mail']; // i get this from other page include 'admin/conn.php'; $get = "SELECT * FROM `users` WHERE `mail` = '$mail'"; $res = mysqli_query($conn, $get); if (!isset($pscoo) && !isset($dthsh)) { while ($row = mysqli_fetch_assoc($res)) { $slt = $row['salt']; $hsh = $row['hash']; $cnct = $slt.$pass; if (password_verify($cnct, $hsh)) { // do smth } else { // reject } } } ?> 
First of all I would suggest to comply to following OWASP Application Security Verification Standard (ASVS) password handling requirements:
2.1.1 Verify that user set passwords are at least 12 characters in length.
2.1.2 Verify that passwords 64 characters or longer are permitted
2.1.3 Verify that passwords can contain spaces and truncation is not performed
2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system’s password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new nonbreached password
2.1.8 Verify that a password strength meter is provided to help users set a stronger password.
2.1.9 Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
NOTE: ASVS summarizes the best practice defined by security researchers, big security players (NIST) and common best practice. The requirements described in 2.1 chapter are Level 1 requirements meaning, that actually all newly built systems should fulfil them.
After doing of what is required above the possibility of collisions is minimal (negligible), but will always be there and should NOT be prevented. (Sometimes by preventing duplicate passwords people create a mechanism for user/password enumeration which is bad.)
Now, regarding your code. This place keeps me wondering:
$slt = $row['salt']; $hsh = $row['hash']; $cnct = $slt.$pass; Usually a Key Derivation Function like bcrypt, scrypt, PBKDF2 should not need the salt to be concatenated to the password manually. Doing it like this would mean, you are not using a KDF, but some kind of hashing function (which is suboptimal from security perspective)… Suboptimal is wrong.
By the way, is this a SQL injection vulnerability: $get = "SELECT * FROM 'users' WHERE mail = '$mail'"; in your authentication logic? I so then please have this fixed ASAP and update your question on StackOverflow too.
