Username, Password, Salting, Encrypting, Hash - How does it all work? [duplicate]

Answer 1

Password encryption is one-way encryption (or rather its suppose to be in a secure site). That is to say you take the password and you make a hash form it. bcrypt for example is the acceptable standard for doing this today.

If its one-way encryption a lot of people wonder how it can check a password. But you just hash the password the user submits and compare it to what hash you stored in the database. This way if your database is stolen an attacker has to work a lot harder.

The problem with just hashing a password is easily brute forced or rainbow tabled. You can google rainbow table to learn more on that. But essentially its a way to turn these hashes back into passwords.

Enter salting. Salting is adding random data essentially to every password. This trumps rainbow tables. Meaning a compromised database will mean brute force. Which if you're using a hash system like bcrypt takes a lot of time and effort for the attacked.

Having said all that. Best not to reinvent the wheel. Just use a known good authorization system if you can.

Answer 2

If you rule out captchas, try limits, lockouts, et cetera... then yes. You just have to brute force the plain text string.

However, that does take time - at the very least, it's bounded by the rate at which the server will respond to login requests. Even if the developer doesn't add any measures to prevent brute forcing, the server itself can only go through the encryption + verification process so quickly, and can only handle so many parallel requests.

That said, this is why it's important to

• As a user, use a strong, hard to brute-force password
• As a developer, have adequate measures to prevent brute-forcing of your login process

---

Hashing and salting passwords isn't to protect against people who brute force the natural login process (there are other things that protect against that). Instead, they're to protect against potential compromise of the password storage itself (e.g. someone dumping the contents of the database).

Both hashing and salting serve to decrease the speed at which someone with access to the stored passwords can retrieve the plain text string they'd need to be able to go through the natural login process (of your site or other sites, given that passwords are commonly shared between sites) without tripping anti-brute-forcing security measures.

Answer 3

One problem with brute force attacks is when you use a fast encryption like SHA1 or MD5. These functions are build to run the password through an algorithm fast. Instead you could use the Blowfish method, which im no expert on, but long story short it takes more calculation for a returned value, than SHA1 or MD5. This means it may take 5 years to brute force a password, hashed with Blowfish because of calculation time.

The next example is made with SHA1 and MD5, so it's vulnerable to bruteforce attacks, however the salt part should be OK to use:

$salt = md5(microtime().uniqueid());

This will output a unique 32 charecter salt, which you will put together with the password.

$passwod = $_POST['password'];
$hashed_password = sha1($password.$salt);

Now you have to store both the password and the salt in the database. And when you check the user inputtet password you get the salt, and hash the whole thing.

$temp_pass = $_POST['temp_pass'];
$salt = //from database;
$database_pass = //hashed pass from database;

$hashed_temp_pass = sha1($temp_pass.$salt);

if(hashed_temp_pass == $database_pass){
//Welcome user!
}
else{
//go away
}

Answer 4

The idea of hashing and salting is more to prevent someone from taking user passwords if the database itself is compromised. If the passwords are stored as salted and hashed strings, the attacker can't just use them to access a user's account on another site.

Answer 5

See my answer here

And you should generate unique salts for each entry when you create the hash.