How does password verification works without using the salt?

[poohitan]

More a question rather then an issue on this package.

How does password verification works if we doesn't pass the salt to the verification function?
Every password has a random salt, and as I understand, hash function works like this: hash(password + salt).

But verification function takes only password as an argument, so as I understand it can't generate the same hash as original, because hash(password) and hash(password + salt) will differ. So how does verification function know what salt it should use to verify every specific password?

[ranisalt]

The salt is stored in the hash, it's the field before the last on the resulting hash. When you verify, it (tries to) take the salt from the hash and reuse.

Example: for $argon2i$v=19$m=4096,t=3,p=1$c29tZXNhbHQ$iWh06vD8Fy27wf9npn6FXWiCX4K6pW6Ue1Bnzz07Z8A, the salt is c29tZXNhbHQ (base64 encoded, padding stripped)

[poohitan]

So simple :). Thanks for the answer @ranisalt.

[ranisalt]

Hahaha yes. Also note that other parameters are stored, such as the algorithm (i, d or id) the version (19 for 1.3, 16 for 1.0), memory cost, time cost and parallelism, so you don't have to inform them too.

[aramando]

Quick follow-up question, hope you don't mind: doesn't it somewhat defeat the point to have a "hash" which contains the salt and other hashing parameters in plain text? Or is it just about preventing rainbow tables being used to decypher whole sets of user data?

[ranisalt]

Salts are meant to defeat rainbow tables, while parameters (time, memory and threads) are meant to defeat ASICs/FPGAs which have low memory and less powerful processors. If you use a random salt and high memory and processor usage, you basically slow down a cracker to a brute-force crawl.

As an exercise, think how would you salt your passwords without storing the salt and parameters somewhere else.

[aramando]

Thanks, I didn't fully appreciate the role of salts and thought they were supposed to be kept unknown to any attacker who might obtain the password hashes - and yes, I had already realised that if it wasn't obtainable from the password hash then it would just be in its own field on the same user record!

[ranisalt]

@aramando parallel to salts, there are peppers (not supported by this lib - yet). Peppers are not random, and are not stored in the hash. They exist because should your passwords be stolen, there would still be a key missing to crack them. Maybe that's what you want? :P

[aramando]

@ranisalt Heh, peppers - I like it! I didn't know the name but I've used them, and had previously known them as secrets or something more generic like that. Thanks.

[ranisalt]

Computer security guys are funny