How to Safely Store Your Users' Passwords in 2016 • Hacker News Board

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

#41

Post by warfangle » Wed, Feb 17, 2016, 5:57 PM UTC

zwily wrote: post #21

phillipburch wrote: post #19

Earlier quoted context omitted.

Or you could just use the async versions.... https://www.npmjs.com/package/bcrypt-nodejs

Does that library do the calculations in a thread pool, or is it just async on the main thread? If the latter (which seems mostly likely), then it won't matter.

It looks like that one is pure JS, using native node crypt functionality for randomness.

The one recommended in the article[0] actually includes a blowfish C++ binding, with both synchronous and asynchronous methods for comparing and hashing. That binding uses NAN[1] to queue AsyncWorkers. NAN uses libuv[2] behind the scenes to launch a thread[3].

0. https://www.npmjs.com/package/bcrypt

1. https://github.com/nodejs/nan

2. https://github.com/libuv/libuv

3. https://blog.scottfrees.com/building-an-asynchronous-c-addon...

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

#42

Post by daveloyall » Wed, Feb 17, 2016, 5:58 PM UTC

sarciszewski wrote: post #37

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.

The article offers specific advice for Java-without-libsodium, but it offers no such specific advice for Java-with-libsodium.

There would appear to be three distinct Java bindings of libsodium.

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

#43

Post by [deleted] » Wed, Feb 17, 2016, 6:00 PM UTC

herge wrote: post #6

josefdlange wrote: post #3

Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?

== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack. hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.

[deleted]

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

#44

Post by TeMPOraL » Wed, Feb 17, 2016, 6:01 PM UTC

bigbadgoose wrote: post #23

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")

great, thanks. because i was about to reply with "on a piece of paper in the same place you store your diamonds"

I'm starting to think that if you're a security-conscious person and understand what's at stake, then the best solution for you would be to simply memorize it. Your mind is the only place from which an attacker can't steal your password without drugging you or beating you up until you give it out.

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

#45

Post by zwily » Wed, Feb 17, 2016, 6:03 PM UTC

phpnode wrote: post #34

zwily wrote: post #27

Earlier quoted context omitted.

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.

Yep you're right - disregard what I said above. :)

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

#46

Post by warfangle » Wed, Feb 17, 2016, 6:06 PM UTC

rcconf wrote: post #9

If you're using node.js and you use these hashing methods, your entire server is going to pause for 0.5 seconds on a login because it runs on a single thread. Goodbye to all of your server performance. You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

Incorrect; the first hashing method recommended uses a native CPP binding which launches a thread to execute both hashing and comparing.

Unfortunately, the example used for the bcrypt node module is the async form of hashing. That library exports both sync and async forms of hash/compare.

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

#47

Post by jordonias » Wed, Feb 17, 2016, 6:06 PM UTC

I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they confirmed it. This is an example of how to not handle passwords in 2016.

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

#48

Post by cperciva » Wed, Feb 17, 2016, 6:09 PM UTC

sarciszewski wrote: post #38

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.

Scrypt is based on PBKDF2.

No, it really isn't.

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

#49

Post by sarciszewski » Wed, Feb 17, 2016, 6:10 PM UTC

cperciva wrote: post #48

sarciszewski wrote: post #38

Earlier quoted context omitted.

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.

Scrypt is based on PBKDF2. No, it really isn't.

I could have sworn it used PBKDF2-SHA256 and Salsa20/8 internally, which is what I meant by "based on".

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

#50

Post by cperciva » Wed, Feb 17, 2016, 6:14 PM UTC

sarciszewski wrote: post #49

cperciva wrote: post #48

Earlier quoted context omitted.

Scrypt is based on PBKDF2. No, it really isn't.

I could have sworn it used PBKDF2-SHA256 and Salsa20/8 internally, which is what I meant by "based on".

It also uses xor internally, but I wouldn't say that scrypt is based on xor. scrypt does not use PBKDF2 for any PBKDF properties; it's just a convenient arbitrary-length-output hash function. I would have used a sponge if they had been widely available when I created scrypt.