:salt_do_not_supply option renamed about ruby-argon2 HOT 4 CLOSED

@jeremyevans I could be off-base, but it sounds like you may be confusing the purpose of the salt and the pepper.

The salt, from what I understand, is intended purely to protect against rainbow table attacks. There is no issue with an attacker having access to both the hash and the salt, as the salt has already done its job in protecting against pre-computation attacks.

Having a secret stored separately from the hash is the duty of the pepper, which this library does support natively within the public API. What you've described using the salt for within Rodauth, should instead be the pepper which is kept entirely separate from the database storing password hashes/salts.

This is why the salt is plaintext (b64 encoded) and included in the final digest Argon2 produces; it's not actually important for it to be kept separate from the hash for it to fulfill its purpose.

(Again, grain of salt. I could totally be wrong on this. This is just the understanding I've built up while working with Sorcery)

from ruby-argon2.

@athix You are off base :). With a password hash, an attacker can try to bruteforce the password. Without a password hash, an attacker cannot. With Rodauth's design, because an attacker doesn't have access to the hash itself, the only way they can bruteforce a password is to issue a database query for each check (candidate password hashes are checked using a security definer database function that doesn't provide an attacker access to the actual password hash), which is going to be much slower than attempting to bruteforce the password on an FPGA/ASIC.

Let's say you are an attacker and you have access to a password hash. It doesn't matter if the password is peppered or not, you can still try to bruteforce it. Additionally, if an attacker has compromised your environment to such an extent that they have access to password hashes, they likely have access to the pepper as well, in which case the cost of bruteforcing the hash is the same as having no pepper at all.

FWIW, Rodauth has support for password peppering as well. Peppering can be useful when you cannot use Rodauth's more secure default approach of checking passwords using a database function.

from ruby-argon2.

Breaking changes are not on. I'm reverting this immediately. It's not like something named salt_do_not_supply was confusing to users.

from ruby-argon2.

@jeremyevans

Let's say you are an attacker and you have access to a password hash. It doesn't matter if the password is peppered or not, you can still try to bruteforce it.

From what I've researched so far, this is exactly the purpose of the pepper, per Argon2 README:

The secret parameter, which is used for keyed hashing. This allows a secret key to be input at hashing time (from some external location) and be folded into the value of the hash. This means that even if your salts and hashes are compromised, an attacker cannot brute-force to find the password without the key.

That said, this library is @technion rodeo, and it looks like this is being reverted either way. Problem solved 🎉

from ruby-argon2.