Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Safely Store Your Users' Passwords in 2016

paragonie.com

Post reply on HN
Print view View original

31–40 of 321 posts

Re: How to Safely Store Your Users' Passwords in 2016

#32

Post by Freaky »

> base64_encode(hash('sha384', $password, true))

> ...

> The above construction may invite theoretical concerns about entropy reduction (i.e. 72 characters of raw binary without any NUL bytes comes out to about 573 bits of possible entropy, but a SHA-384 hash outputs are clearly limited to 384 bits).

Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle. If you're brute-forcing search spaces this big you're no longer looking to recover a password, but find a collision.

Re: How to Safely Store Your Users' Passwords in 2016

#34

Post by phpnode »

zwily wrote: post #27
sotojuan wrote: post #22

Earlier quoted context omitted.

Everything is asynchronous but the linked article uses the synchronous versions of the functions for some reason... async versions exist and are recommended[1] [1] https://github.com/ncb000gt/node.bcrypt.js#async-recommended

Do the async methods actually execute on a thread pool though? Or do they use enough async methods internally to periodically release the main thread enough to keep it responsive? From a quick glance at the source, the answer to the first is no.

This one is truly async, it uses a libuv managed thread pool.

Re: How to Safely Store Your Users' Passwords in 2016

#35

Post by sarciszewski »

Freaky wrote: post #32

> base64_encode(hash('sha384', $password, true)) > ... > The above construction may invite theoretical concerns about entropy reduction (i.e. 72 characters of raw binary without any NUL bytes comes out to about 573 bits of possible entropy, but a SHA-384 hash outputs are clearly limited to 384 bits). Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle. If you're bru…

> Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle.

This was added in response to a point that a couple people (or perhaps a convincing sockpuppeteer) raised and tried to use to decry the entire article. You're lucky to get 60 bits of information entropy in any given user's password, as is. The "theoretical weakening" here isn't a practical concern: "2^192 security" is still boring crypto.

Re: How to Safely Store Your Users' Passwords in 2016

#37

Post by sarciszewski »

TorKlingberg wrote: post #30

For some reason the article completely fails to link to libsodium: https://download.libsodium.org/doc/

> For some reason the article completely fails to link to libsodium: https://download.libsodium.org/doc/

The "bindings for most programming languages" link goes to the libsodium documentation, but I'll add a link in more contexts.

Re: How to Safely Store Your Users' Passwords in 2016

#38

Post by sarciszewski »

AdmiralAsshat wrote: post #31

I had no idea that PBKDF2 had fallen so much in recent years. I still remember the 1Password team extolling its virtues five years ago: https://blog.agilebits.com/2011/05/05/defending-against-crac...

Correction: Scrypt actually uses PBKDF2 internally. (Previously said "scrypt is based on PBKDF2" but that's a loaded statment.)

PBKDF2 is an improvement over PBKDF1 (and other naive iterated hash constructions), but attacks got better and better defenses are called for.

Re: How to Safely Store Your Users' Passwords in 2016

#40

Post by sarciszewski »

privong wrote: post #5

For anyone who reads the comments before clicking the article, the subject is storing your users' passwords, not managing your passwords for a variety of services. I had interpreted it as the latter. A better title might be "How to Safely Store Your Users' Passwords in 2016". (Title is currently: "How to Safely Store a Password in 2016")

You're right. I've updated the article title to avoid this ambiguity.
Post reply on HN