@niwinz I have a question regarding buddy-hashers

tell me 😄

I’d like to encrypt passwords in a consistent way

I mean encrypting the same password should give the same result

I tried to play with hashers/derive

But the problem is that the :salt is implicit

hmm

I think just passing fixed salt should work

let me try it...

Probalby, but how do I generate a good salt?

I need to use (nonce/random-bytes 8)?

user=> (def salt (nonce/random-bytes 16))
#'user/salt
user=> (hs/derive "foo" {:salt salt})
"bcrypt+sha512$a19816aad5a6dea6c3d927a0fbca8e75$12$c679579c550318d9294c562540526860fc6e8877c7870f85"
user=> (hs/derive "foo" {:salt salt})
"bcrypt+sha512$a19816aad5a6dea6c3d927a0fbca8e75$12$c679579c550318d9294c562540526860fc6e8877c7870f85"
user=> (hs/derive "foo" {:salt salt})
"bcrypt+sha512$a19816aad5a6dea6c3d927a0fbca8e75$12$c679579c550318d9294c562540526860fc6e8877c7870f85"

seems to work

the salt size depends on the final algorithm

for default bcrypt you need 16 bytes (or 128 bits) salt

if you don't provide a salt, a randomly one is generated

of the size approriate for the chosen algorithm

How do I serialize the salt?

I mean I don’t want to generate a new salt each time my app loads...

The question here is why you want a fixed salt?

it decreases the security of the derived password

Oh. Maybe I’m missing something (I’m not a security expert)

I don’t want to store plain passwords in the db

when a password is derived with derive function the salt is publicy appended to the result:

bcrypt+sha512$a19816aad5a6dea6c3d927a0fbca8e75$12$c679579c550318d9294c562540526860fc6e8877c7870f85

the bold part is the randomly generated salt for that derived password

I'm not clearly understand why you need a fixed salt.

@viebel do you just want to follow the best practice for storing passwords?

@dm3 yes

I’d love to follow the best practice

You only need use derive for hash password and later check for verify...

yep, in this encoding scheme the salt is stored together with the algo, iteration count and the hash

so check can get everything it needs from the string

you derive(password) -> hash, store the hash, then on next login check(password, hash)

I'm pretty security concerned and buddy-hashers follows the well established best practices for password hashing

it’s confusing when you don’t know that all the algo parameters are stored in the result of derive

not sure if documentation mentions that

If you find a doc or any other improvement, I'm open to review it 😄

This is exactly what confused me

By the way, why is it better to have a random salt stored in the encrypted password?

it’s just more convenient, e.g. you only need one column/attribute/property in the database for the whole thing

or do you mean why salt is needed in general?

I mean: why not using the same salt for all the passwords

?

you can, but then the attacker only needs to construct a single rainbow table

to try breaking the (stolen) passwords

if you have a salt per password, this becomes infeasible

basically this avoid detect duplicated passwords

in the database

because the salt additionally to simple append to the final password string it is also feeded into the hasher

the salt should be stored in order to posterior verification, without knowing that salt it will be imposible verify the clear password with "encrypted" one

hm, duplicate passwords - that’s another interesting reason

here, a good explanation of my point: http://security.stackexchange.com/questions/16686/recompute-rainbow-table-with-salt

Thanks for your explanations @dm3 and @niwinz

BTW funcool is really really cool 😎

thanks! \o/