ECU Handbok Datalagring

Databas

API

Säkerhet

Beekeeper Studio

Entity Framework

Explore

Krypto

Lösenord-hashsalt

⁠

Det “hashade” lösenordet tillsammans med det slumpade “saltet” sparas tillsammans i databasen.

När användaren skickar in sitt lösenord sedan vid inlogg, så jämför backenden det hashade lösenordet som skickas in med det tidigare sparade hashade lösenordet med saltet i databasen . Om de ger samma hashade fingeravtryck så godkänns inlogget.

Salting is simply the addition of a unique, random string of characters known only to the site to each password before it is hashed, typically this “salt” is placed in front of each password. The salt value needs to be stored by the site, which means sometimes sites use the same salt for every password

Bcrypt

⁠

bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher and presented at USENIX in 1999.

Mer info om Saltning av lösenord

Attacking Unsalted Passwords

To start, the attacker could try a

dictionary attack⁠

. Using a pre-arranged listing of words, such as the entries from the English dictionary, with their computed hash, the attacker easily compares the hashes from a stolen passwords table with every hash on the list. If a match is found, the password then can be deduced.

⁠

⁠

Two different hash functions can produce the same hash; however, the risk of this happening is extremely low. But, how do attackers know which hash function to use?
It's not too hard⁠
.

Fortunately, despite choosing the same password, alice and bob chose a password that is not easily found in a dictionary: dontpwnme4. Our friend mike, on the other hand, chose friendship as his password which is a direct entry in the English dictionary. mike is at high risk of being breached through a dictionary attack; the risk for alice and bob is no different. To come up with a password such as dontpwnme4, the attacker could use special dictionaries such as

leetspeak⁠

to crack the password.

Both dictionary attacks and brute-force attacks require the real-time computation of the hash. Since a good password hash function is slow, this would take a lot of time.

Dictionary -> use lists from a dictionary Brute force -> using random characters

What kind of password profiling they are trying to make.

Cracking Unsalted Hashes with Tables

An attacker has two types of tools at disposal: hash table and rainbow table. Definition of both and how they can help with cracking table. Hash tables to be exhausted first. Additional results use a rainbow.

Hash tables = fast lookup, but long computation (if you were building one from scratch), more space. Rainbow table = slow lookup because you have to run through the hash algorithms many times, less space.

A hash table can make the exploitation of unsalted passwords easier. A hash table is essentially a pre-computed database of hashes. Dictionaries and random strings are run through a selected hash function and the input/hash mapping is stored in a table. The attacker can then simply do a password reverse lookup by using the hashes from a stolen password database.

The main difference between a hash table attack and a dictionary and brute-force attack is pre-computation. Hash table attacks are fast because the attacker doesn't have to spend any time computing any hashes. The trade-off for the speed gained is the immense amount of space required to host a hash table. We could say that a hash table attack is a pre-computed dictionary and/or brute-force attack.

Since time and space are limited, the attacker that designs and computes the hash table may want to process the most commonly used passwords first. Here is where alice and bob could be at a much higher risk if dontpwnme4 is in that common-password list. Large common-password databases are created using frequency analysis across passwords collected from different publicly leaked breaches.

The strength of hash tables comes from volume not computation speed and the volume is huge! Each data breach adds to this volume. For a list of companies that have been breached visit the

pwned websites list of haveibeenpwned.com⁠

"There are often 'breaches' announced by attackers which in turn are exposed as hoaxes. There is a balance between making data searchable early and performing sufficient due diligence to establish the legitimacy of the breach." -
Troy Hunt⁠
⁠

Faster CPUs and GPUs, distributed computations, and weak algorithms are making cracking a password much easier. However, because cracking password hashes these days is more challenging than credential stuffing, it is always a good idea to use

MFA (Multi-factor Authentication)⁠

Mitigating Password Attacks with Salt

To mitigate the damage that a hash table or a dictionary attack could do, we salt the passwords. According to

OWASP Guidelines⁠

, a salt is a value generated by a

cryptographically secure function⁠

that is added to the input of hash functions to create unique hashes for every input, regardless of the input not being unique. A salt makes a hash function look non-deterministic, which is good as we don't want to reveal duplicate passwords through our hashing.

Let’s say that we have password farm1990M0O and the salt f1nd1ngn3m0. We can salt that password by either appending or prepending the salt to it. For example: farm1990M0Of1nd1ngn3m0 or f1nd1ngn3m0farm1990M0O are valid salted passwords. Once the salt is added, we can then hash it. Let's see this in action:

Prepending the Salt

Password: farm1990M0O

Salt: f1nd1ngn3m0

Salted input: f1nd1ngn3m0farm1990M0O

Hash (SHA-256): 7528ed35c6ebf7e4661a02fd98ab88d92ccf4e48a4b27338fcc194b90ae8855c

Appending the Salt

Password: farm1990M0O

Salt: f1nd1ngn3m0

Salted input: farm1990M0Of1nd1ngn3m0

Hash (SHA-256): 07dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

The hashes were calculated using the following Python code:

import hashlib

string = "saltedpassword"

hashlib.sha256(string.encode()).hexdigest()

This demonstrates the importance of using unique salts. Let’s say that we decide to always append the salt to the passwords. If two users use the same password, we are just creating longer passwords that won’t be unique in our database. Both salted passwords would hash to the same value. But, if we choose another salt for the same password, we get two unique and longer passwords that hash to a different value. Let's visualize this through an example:

Alice and Bob decide to use both the same password, farm1990M0O. For Alice, we'll use f1nd1ngn3m0 again as the salt. However, for Bob, we'll use f1nd1ngd0ry as the salt:

Hashing and Salting Alice's Password

User: Alice

Password: farm1990M0O

Salt: f1nd1ngn3m0

Salted input: farm1990M0Of1nd1ngn3m0

Hash (SHA-256): 07dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

Hashing and Salting Bob's Password

User: Bob

Password: farm1990M0O

Salt: f1nd1ngd0ry

Salted input: farm1990M0Of1nd1ngd0ry

Hash (SHA-256): 11c150eb6c1b776f390be60a0a5933a2a2f8c0a0ce766ed92fea5bfd9313c8f6

Different users, same password. Different salts, different hashes. If someone looked at the full list of password hashes, no one would be able to tell that Alice and Bob both use the same password. Each unique salt extends the password farm1990M0O and transforms it into a unique password. Additionally, when a user changes their password, the service should also generate a new salt.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.