
How to Safely Store a Password in 2016 - carlesfe
https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016
======
carlesfe
The TL;DR seems to be "use libsodium". I'd love to see some discussion and
first hand experiences on that, since I'm no crypto expert.

~~~
creshal
Libsodium is a well-understood, modern crypto library that's slowly becoming
the gold standard in applied crypto. It's _very_ hard to find a better library
for any given purpose, and _very, very_ easy to use most of those alternatives
wrong.

The other TL;DR is: Argon2 is not yet ready and bcrypt is good enough that
moving to scrypt is not necessary.

That's a bit surprising to me, I didn't realize that scrypt's safety margin
over bcrypt is that small in practice.

~~~
sarciszewski
> Argon2 is not yet ready and bcrypt is good enough that moving to scrypt is
> not necessary.

I'd like to also specify that Argon2's perceived lack of readiness is, well,
perceived. The attack mentioned in the article might prove to not be worth
mitigating, or it will lead to a new flavor (dubbed "Argon2x" here as a
hypothetical nickname).

~~~
creshal
> The attack mentioned in the article might prove to not be worth mitigating,
> or it will lead to a new flavor

So, it's not clear whether you can keep using Argon2i or should use Argon2x
instead.

In other words: It's not yet ready.

------
WorldMaker
How about: __Don 't __? It 's 2016: we have too many password databases on too
many servers. Let's focus more on techniques like Passwordless
(passwordless.net) and federation and less on "every website needs to store
its own password database", please.

~~~
sarciszewski
That's an option for some people, not an option for everyone.

~~~
WorldMaker
That's the conversation I think we need to have as a developer community. Why
isn't it an option? Why isn't something like Passwordless the new default?

From a security standpoint it has no worse a security stance than existing
password systems: you have to have a one-time token based Forgot Password
system. Humans are extremely fallible at storing passwords and in 2016 it's
considered unacceptable a UX to not include a "Forgot Password" button. From
that stance, Passwordless is simply "Forgot Password"-only login. In 2016 if
you have a password system and a "Forgot Password" system, I guarantee you
already have "Forgot Password"-only users. With modern lockouts and password
requirements, we've essentially trained entire subsets of (even not-so-
forgetful) users to click on "Forgot Password" before even bothering to
attempt a password. "Forgot Password" is already, _de facto_ , the "one true
login button" on the web.

Are we doomed to this miserable UX flow for eternity, simply because it's now
the entrenched platform default?

~~~
SAI_Peregrinus
Passwords (or passphrases) are really the only way to securely verify the
"something only you know" factor of authentication. Alternatives either
devolve to storing a password somewhere else (password safes, passwordless,
etc) or to "something only you have" (tokens, smart cards, biometrics). It's
easily arguable that the "something only you have" factor should be the
primary factor, especially for low security systems, with "something only you
know" being the secondary factor for high-security systems, but the economics
have tended to reverse the situation. It's a lot cheaper to ask a user to
memorize a password than to get smart cards or fingerprint scanners for
everyone.

~~~
WorldMaker
The Passwordless approach falls under "something only you have", and does make
that the primary approach: tying your login security to your possession
(lease) of your email address. Uses the same one-time token system that a
Forgot Password or a "Verify Your Email Address" approach uses.

