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

21–30 of 321 posts

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

#21

Post by zwily »

phillipburch wrote: post #19
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

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.

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

#22

Post by sotojuan »

ARussell wrote: post #15
lukev wrote: post #11

Earlier quoted context omitted.

I think this says more about node.js than it does about the proper way to secure a password.

Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.

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

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

#23

Post by bigbadgoose »

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"

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

#24

Post by sarciszewski »

tptacek wrote: post #13
herge wrote: post #6

Earlier quoted context omitted.

== 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.

Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.

Precisely what Thomas said.

Using == instead of hmac.compare_digest is unlikely to be a source of vulnerabilities in your application, but it's a good habit to get into whenever you touch cryptography.

See also: https://news.ycombinator.com/item?id=10345965 (pg. 33-36, 42-43 of the PDF)

    Again consider timing leaks.
    Many interesting questions:
    How do secrets affect timings?
    How can attacker see timings?
    How can attacker choose inputs to influence how secrets affect timings?
    Et cetera.
    
    The boring-crypto alternative: crypto software is built from instructions 
    that have no data flow from inputs to timings.
    Obviously constant time.

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

#25

Post by Someone1234 »

tptacek wrote: post #13
herge wrote: post #6

Earlier quoted context omitted.

== 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.

Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.

This is "mostly true" but with an edge case...

If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password.

For example, let's say your rainbow table has 20 million password-hash combinations and your hash length is 33 letters, for every letter I know I could drop literally millions of hashes I know it ISN'T. With just the first four letters I could drop it by almost 60% (although my maths here might be completely wrong, it is actually pretty complicated to determine). But there's no real limit on how many letters you could drop from the hash with a timing attack, you could turn someone's password into a 1 in 62 chance.

The TL;DR: Use a per user salt. But a timing immune comparison definitely is "defense in depth" in case there is a bug elsewhere that breaks salts.

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

#26

Post by dfischer »

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

Have any examples of how to properly handle it with node? Isn't it just the typical callback pattern?

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

#27

Post by zwily »

sotojuan wrote: post #22
ARussell wrote: post #15

Earlier quoted context omitted.

Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.

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.

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

#29

Post by phpnode »

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 does it on the main thread, pseudo-async, so I agree with you, you should not use this library. Look for a native module instead.
Post reply on HN