I have the password "data/hash", next what?

Question

In theory, passwords should not be stored in plain text and also it should be avoided to store them as a simple hash, something like md5(password).

Is recommended to store the output of the function that uses algorithms/ciphers like bcrypt, script, PBKDF, passed to the password with some salt.

But once the database/file with passwords has been compromised for example a file containing data like this:

id, password

12, $2a$10$zkeaH43RM9Ep5.KPcyXWYuCaVSbKmmXaKLztvCa0G867ItEpvx4fa  (bcrypt)

12, 05ffaebcca41770af425d4ba9b4e7bcdff532237dca931c192a36d94db7307d4 (scrypt)

12, JDJhJDEwJHprZWFINDNSTTlFcDUuS1BjeVhXWXVDYVZTYkttbVhhS0x6dHZDYTBHODY3SXRFcHZ4NGZh (base64 ofuscation bcrypt)

As an attacker, from the first look, I can see that in first case bcrypt with a cost of 10 is been used, for the second I have just a length of 64 in where probably salt is included, the third one ends being the base64 just obfuscating bcrypt

base64($2a$10$zkeaH43RM9Ep5.KPcyXWYuCaVSbKmmXaKLztvCa0G867ItEpvx4fa) 

just to mention some random examples.

So once this information has been compromised, besides following a procedure for changing password etc, what could be the best way to store the passwords that at least could delay more the process of finding how it was generated and have more time for allow all users to reset/change passwords.

Or asking different, while having this kind of data what an attacker normally start to do? and based on this what could be improved so that it could be more difficult to find a pattern, start cracking the passwords, etc.

Answer 1

Increase the work value, that'll exponentially make a hackers life harder. Use a random salt for every password, that'll make it so a hacker needs to generate attack dictionaries unique for each user. Use a hardcoded pepper in your application to add a hidden element to your hashes that the hacker would be forced to brute force.

Any attempt to hide the method you used to hash the password is security by obfuscation, which itself isn't really security.

There's quite a few scenarios that can occur if an attacker gets access to your database, I'll go over a few of them.

No salt/same salt for every entry. In this scenario I, the attacker, can crack all of your users password in one go. Since the only variation I have to worry about is the password itself, I can hash once and check against all 10,000 of your users.

Unique salt for every entry, salt appended to hash. In this scenario, I can only crack your users passwords one at a time. Let's say of your 10,000 users, 300 had the password "password". Instead of me figuring out 300 of your users had that password at once, I'd need to rehash with the users salt 10,000 times to check them all.

Unique salt + hardcoded pepper. This scenario is dependent on how deep of an intrusion you suffer. If they get access to your application servers, they could sniff out the pepper. If not however, instead of me having to guess the password, I also have to guess the pepper. Only problem with that is I have no way of telling if I'm close. Should you choose to use a pepper that is 128 characters long, initially generated using a cryptographically secure library, I would have to brute force that on top of the password, virtually destroying dictionary based attacks.

Our goal is to make it hell for an attacker to crack the passwords, by doing things in such a way that the attacker has no choice but to sit and wait an eternity.

On a side note, if your password database was ever compromised you should immediately flag all the accounts, and on next sign in require the user to follow the password reset procedure, not the change password procedure. This allows you to verify the users identity by using a side channel to ensure authenticity of the request.

Answer 2

If you want time, use salt and high iteration counter to make calculating costly. Optionally, also a pepper that is stored on the server side, possibly outside the root of the app and call for it when needed. It depends on what kind of app you have but for websites it's important to do this in case PHP stops parsing the code.

In such case, an attacker would also get the formula on how the hash is generated in the first place. But would still lack the pepper. If the server is breached, on the other hand, the attacker gets both, as well as access to your database.

From this point on, you're in serious trouble because the attacker now knows how to generate the hash, knows what the salt and pepper values are which means he can easily temporarily change the password hash to his favourite password and access the account of his own choosing.

He may also decide to scan or export your whole database, which means stealing your information from the source. Depends on how big your database is and if your app uses just one database.

So basically, cracking passwords comes last in anticipation that plenty of users still use same passwords for multiple accounts. Which brings us to back to original answer. Use unique salt and from 5k - 10k iteration rounds to make calculating the hashes costly. You can go up to a million but anything above 10k could cause performance issues. This way, it could take ages to crack reasonable passwords. It is why some websites demand using Capital letters, numbers and special chars...simply to increase the char pool.

On a side note, instead of going to such lengths, an attacker would rather extract your plain password to whatever account he wants with a keylogger or DNS redirection attack to a bogus site. He'll go after your device instead of trying to breach the server. If that is one and the same, then better protect your server, which means securing it from remote as well as physical breach.