Fork me on GitHub
#funcool
<
2017-03-02
>
Yehonathan Sharvit13:03:49

@niwinz I have a question regarding buddy-hashers

niwinz13:03:04

tell me 😄

Yehonathan Sharvit13:03:16

I’d like to encrypt passwords in a consistent way

Yehonathan Sharvit13:03:38

I mean encrypting the same password should give the same result

Yehonathan Sharvit13:03:49

I tried to play with hashers/derive

Yehonathan Sharvit13:03:10

But the problem is that the :salt is implicit

niwinz13:03:09

I think just passing fixed salt should work

niwinz13:03:12

let me try it...

Yehonathan Sharvit13:03:35

Probalby, but how do I generate a good salt?

Yehonathan Sharvit13:03:58

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

niwinz13:03:25

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"

niwinz13:03:31

seems to work

niwinz13:03:49

the salt size depends on the final algorithm

niwinz14:03:04

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

niwinz14:03:40

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

niwinz14:03:50

of the size approriate for the chosen algorithm

Yehonathan Sharvit14:03:59

How do I serialize the salt?

Yehonathan Sharvit14:03:31

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

niwinz14:03:53

The question here is why you want a fixed salt?

niwinz14:03:11

it decreases the security of the derived password

Yehonathan Sharvit14:03:32

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

Yehonathan Sharvit14:03:44

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

niwinz14:03:14

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

niwinz14:03:26

bcrypt+sha512$a19816aad5a6dea6c3d927a0fbca8e75$12$c679579c550318d9294c562540526860fc6e8877c7870f85

niwinz14:03:42

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

niwinz14:03:16

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

dm314:03:37

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

Yehonathan Sharvit14:03:00

I’d love to follow the best practice

niwinz14:03:05

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

dm314:03:38

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

dm314:03:47

so check can get everything it needs from the string

dm314:03:54

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

niwinz14:03:35

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

dm314:03:14

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

dm314:03:30

not sure if documentation mentions that

niwinz14:03:29

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

Yehonathan Sharvit14:03:49

This is exactly what confused me

Yehonathan Sharvit14:03:07

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

dm314:03:26

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

dm314:03:00

or do you mean why salt is needed in general?

Yehonathan Sharvit14:03:39

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

dm314:03:03

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

dm314:03:05

to try breaking the (stolen) passwords

dm314:03:14

if you have a salt per password, this becomes infeasible

niwinz14:03:11

basically this avoid detect duplicated passwords

niwinz14:03:17

in the database

niwinz14:03:38

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

niwinz14:03:45

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

dm314:03:14

hm, duplicate passwords - that’s another interesting reason

Yehonathan Sharvit15:03:31

Thanks for your explanations @dm3 and @niwinz

Yehonathan Sharvit15:03:51

BTW funcool is really really cool 😎

niwinz15:03:07

thanks! \o/