Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hydro_pwhash_create without a master key #43

Closed
spinda opened this Issue Apr 5, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@spinda
Copy link
Contributor

spinda commented Apr 5, 2019

I understand the password-hashing API is designed to prevent misuse in the most common cases. But I'm using it to create a hash on a network client which is then transmitted—encrypted, in a secretbox—to a server, which verifies the hash against a password it already holds in plaintext. None of this data is ever stored. Therefore, encrypting the password hash only to wrap it in the transport encryption feels excessive, and requires that I derive a second key just for the password hash.

@jedisct1

This comment has been minimized.

Copy link
Owner

jedisct1 commented Apr 5, 2019

No problem :) You can use NULL as the master key.

@jedisct1 jedisct1 closed this Apr 5, 2019

@spinda

This comment has been minimized.

Copy link
Contributor Author

spinda commented Apr 6, 2019

Great, thanks!

@spinda

This comment has been minimized.

Copy link
Contributor Author

spinda commented Apr 6, 2019

Passing in NULL for the master_key parameter actually leads to a segmentation fault in hydro_secretbox, which (unlike hydro_hash) isn't set up to accept NULL key pointers. Passing in a pointer to an array of NULL bytes works for my purposes, but I could submit a patch to hydro_secretbox if this is intended to work.

@jedisct1

This comment has been minimized.

Copy link
Owner

jedisct1 commented Apr 6, 2019

Being able to pass NULL as the master key was not the original intent. But as you asked, I saw that it would be fine with with hydro_hash, but indeed, we need a key for secretbox.

There's no point in trying to encrypt with a predicable key, so we should skip this if a NULL key is provided. This requires changes to all the current functions, but more importantly, I'm not sure that making encryption optional is a good idea.

This in fine for your use case, but in most applications, encryption is useful, even if this is with a static, hard-coded key.

@spinda

This comment has been minimized.

Copy link
Contributor Author

spinda commented Apr 7, 2019

Alright! I can definitely understand making it harder to veer away from the known-safe path unless the developer is really sure what they're doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.