PhD in Technology of Information, Book Editor,
CCA, Latece, ACM & IEEE member
• Fixed Salting
• Per user Salting
• The most important aspect of a user account system is how user
passwords are protected.
• User account databases are hacked frequently, so you absolutely
must do something to protect your users' passwords if your website is
• The best way to protect passwords is to employ salted password
• Hashing is the transformation of a string of characters into a usually
shorter fixed-length value or key that represents the original string.
• Fast Hashing Algorithms:
How password hashing works?
• The user creates an account.
• Their password is hashed and stored in the database.
• When the user attempts to login, the hash of the password they
entered is checked against the hash of their real password (retrieved
from the database).
• If the hashes match, the user is granted access. If not, the user is told
they entered invalid login credentials.
• Steps 3 and 4 repeat every time someone tries to login to their
Weakness: How password hashing
The simplest way to crack a hash is to try to guess the password, hashing
each guess, and checking if the guess's hash equals the hash being cracked.
The two most common ways of guessing passwords are
• Dictionary Attacks
• Brute Force Attacks
• Lookup Tables
• Reverse Lookup Tables
• Rainbow Tables
• Storing a simple hash is not secure -- if a hacker gains access to your
database, they'll be able to figure out the majority of the passwords
of the users.
1st Enhancement: Adding Fixed Salt
to fast hashing
• Randomize the hashes by appending a random long string, called
a salt, to the password before hashing.
• If the hacker gains access to password hashes (but not the salt), it will
make it much more difficult for the hacker to guess the passwords
because they would also need to know the salt.
Username sha1("salt123456789" + password)
Weakness of fixed salt
• if the hacker has broken into your server, they probably also have
access to your source code as well, so they'll learn the salt too.
2nd Enhancement: Add Per_User
Salt to fast hashing
• Create a new column in the database and store a different salt for
each user. The salt is randomly created when the user account is first
created when the user changes their password.
Username sha1("salt" + password) salt
email@example.com 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 3r3erererwe3
firstname.lastname@example.org cbfdac6008f9cab4083784cbd1874f76618d2a97 effe4f34w3fg3
…. ….. …..
Benefit of Per_User salt
• The hacker can't attack all of your user's passwords at the same time
• So basically, if you have 1 million users, having a per-user-salt makes it
1 million times harder to figure out the passwords of all your users.
• But this still isn't impossible for a hacker to do. Instead of 1 cpu-hour,
now they need 1 million cpu-hours, which can easily be rented from
Amazon for about $40,000.
3rd enhancement: USE Bcrypt OR
PBKDF2 for Slow HAshing
• Bcrypt is a cross platform file encryption utility.
• It takes about 100ms to compute, which is about 10,000x slower than
sha1(). 100ms is fast enough that the user won't notice when they log
in, but slow enough that it becomes less feasible to execute against a
long list of likely passwords.
• For instance, if a hacker wants to compute bcrypt() against a list of a
billion likely passwords, it will take about 30,000 cpu-hours (in AWS
about $1200) -- and that's for a single password.
• Besides incorporating a salt to protect against rainbow table attacks,
Bcrypt & PBKDF2 is an adaptive function: over time, the iteration
count can be increased to make it slower, so it remains resistant
to brute-force search attacks even with increasing computation
Username $bcrypt_id$Log_rounds$128-bit-salt 184-bit-hash
• Don’t use any of these Fast Hashing Algorithms:
• Also, the web is full of bad recommendation about using these
• Bcrypt or PBKDF2 are better even if they are slower.
• Slower does not means it will be noticed by the client (only 100 ms).
• You can control the hashing speed easily by providing the log_rounds
value, because it apply a loop of successive hashing by a maximum of
1. USE a slow hashing functions like Bcript
2. Create a new column in different (or same) database to store a
different salt for each user.
• The salt is randomly created when the user account is first created
when the user changes their password.
• Proposed Result:
• Attacker face a slow hashing
• Attacker can’t hack all password once, but one by one in the worst case.
Id_S1 Username $bcrypt_id$Log_rounds$128-bit-
m $cb$12$fdac6008f9cu4083784cb78u 1
…. …. …..
Table Advanced Salt