Thread by @isocroft

I know you have heard of password #Salts which are similar to Nonces and used to add uniqueness to passwords and protect against pre-computed hashes (rainbow tables).

Did you also know about password #Peppers ? They are equally important too.

In modern web applications of today, you should #Pepper your passwords as well as #Salt them too before hashing them. Here is the order:

Original Password ---> Salt ---> Pepper ---> Hash ---> Store-In-DB.

However, if you #Pepper passwords wrongly. It could be very disastrous!

What do i mean by this ?

Well, the simplest (and safest - very important) way to #Pepper a password is to HMAC(Original_Password, key) it.

HMACs are resistant to length-extension attacks & brutes-force attacks.

There must be a #Pepper key used for the HMAC too

This HMAC key must never be stored in a DB.

when a password #Pepper is applied, it doesn't matter whether the original password (plaintext) is a weak password. It will be gain the right "entropy" which is the most important quality for a password at the end of the day.

I made a slight error with the ordering. Here is the correct order. You have to #pepper a password before #salting it.

Original Password ---> Pepper ---> Salt ---> Hash ---> Store-In-DB.

The HMAC key for a password #Pepper must be stored in some config file in a manner that if the DB is compromised by an attacker, it cannot be accessed.

The next step after #peppering a password is to pass it to a function that will salt and hash it e.g. Bcrypt, Scrypt or Argon2

#Argon2 (id hybrid version) is the best password salting & hashing algorithm, followed by #Scrypt then finally #Bcrypt. Thankfully, popular back-end languages, frameworks/libraries support it ( from #PHP to #Python, #NodeJS, #Elixir - then #Symfony, #Laravel, #Adonis, #Django )

#Argon2 supports #pepper keys in few languages (sad but true). For instance, the `password_hash` function in PHP doesn't allow you set a #pepper key so the only way to do it is to use `hash_hmac` like so:

But, DON'T pepper passwords this way it is wrong! I'll explain why...

Passing the output of `hash_hmac` directly into `password_hash` (which is used by @laravelphp / @CodeIgniter hashing libraries) can lead to the creation of null bytes which can cause problems when verifying these passwords.

See this article for more info: blog.ircmaxell.com/2015/03/securi…

@laravelphp @CodeIgniter As the author of the article i linked to in the preceding tweet says. The problem is not #Argon2 or #Bcrypt but combining hash function that were never designed to be combined directly.

See: php.net/manual/en/func…

So how do we #pepper passwords correctly you might ask ?

@laravelphp @CodeIgniter Well, it quite simple really. We base64 encode the output of `hash_hmac` before we pass it to the hashing function

Like so:

@laravelphp @CodeIgniter If you are using #Laravel , you can do this:

@laravelphp @CodeIgniter You can also use the HMAC(OriginalPass, key) along with #Bcrypt (Not just #Argon2). Lots of people use #Bcrypt because it's popular and mostly uses less memory space than #Argon2 (id) for example.

Finally, i will like to dispel certain user password entry myths

@laravelphp @CodeIgniter Some of these myths have been the source of pain for users on the front-end (from a UX standpoint). They do not hold any water because they neither take away nor add to the security of passwords for a web app.

See this article: dev.to/nathilia_pierc…

Here is a picture except from the above article:

Also, if you feel this is too much info to take in and adhere to OR too much work for you. Then, use auth services like @auth0 @gostormpath @okta.

One last thing, when creating a #Pepper hashing algos 'sha384' & 'sha512' are truly acceptable.

THE END!