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

61–70 of 321 posts

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

#61

Post by jcrawfordor »

jobigoud wrote: post #53
hellofunk wrote: post #28

It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."

Can you expand on this idea? What type of authentication method would replace it? (One that can't be directly linked to the person obviously).

I'm optimistic for the use of physical tokens instead of passwords. In my work environment, a lot of authentication is based on physical token possession plus a password just as a guard against lost devices (password validated by the token, not by the service).

These kinds of systems aren't technically very complex but there hasn't been a lot of traction for them outside of corporate environments. The result is that they tend to be hyper-expensive, unfortunately. Standards like FIDO and the Yubikey are good first steps at pushing this into the consumer space, although they don't offer on-device PIN validation yet.

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

#62

Post by sarciszewski »

rehevkor5 wrote: post #59
sarciszewski wrote: post #57

Earlier quoted context omitted.

The title has been corrected as of ~half an hour ago.

I still see "How to Safely Store Your Users' Passwords in 2016".

That's the correction. Given that the audience for this blog post is developers, I feel that the current title is precise enough.

People who know about password hashing don't need this advice.

People who are storing passwords need this advice.

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

#63

Post by danso »

TeMPOraL wrote: post #44
bigbadgoose wrote: post #23

Earlier quoted context omitted.

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.

The main limitation of that is that your passwords are limited to what you can memorize. Which, for most people, is not very much. Even for just one password, never mind for multiple services. I think if you're a pragmatic security conscious person you'd weigh the trade offs...and I thinking of it as just "simply memorize it" opens you up to other problems.

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

#65

Post by balls187 »

rehevkor5 wrote: post #54
balls187 wrote: post #39

"How to Safely Store a Password in 2016" Don't. Unless it's 100% absolutely necessary. If you must, continue reading on.

The article inaccurately describes generating a password hash & using it as "storing a password".

My point is simply if you can avoid storing user credentials, avoid storing their credentials.

For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more damage, than the data you were trying to secure.

For example, take your run of the mill online todo app. If an attacker got access to the all the todos, vs an attacker got access to the all the todos and all the user passwords (even if securely stored). What is more valuable to an attacker?

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

#66

Post by nostromo »

jordonias wrote: post #47

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 c…

Name and shame.

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

#67

Post by kornish »

mobiuscog wrote: post #17
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.

asynchronous doesn't magically make CPU-intensive tasks faster.

Correct, but it sure does stop your entire single-threaded process from blocking to the detriment of all other requests.

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

#68

Post by corobo »

mobiuscog wrote: post #17
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.

asynchronous doesn't magically make CPU-intensive tasks faster.

It does mean other tasks (e.g. serving pages to visitors) can still be run at the same time as the CPU-intensive task though, like most languages do when it comes to hashing passwords and logging people in

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

#69

Post by wglb »

Someone1234 wrote: post #55
tptacek wrote: post #52

Earlier quoted context omitted.

I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.

I literally don't understand what it is you're getting at. Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage. Therefore it is still common for an application developer to "worry about salts" even if just for…

> While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage.

If your password storage mechanism requires you, the programmer, to generate a salt, you may well be using the wrong password storage mechanism, or using it in the wrong way.

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

#70

Post by Someone1234 »

sarciszewski wrote: post #56
Someone1234 wrote: post #55

Earlier quoted context omitted.

I literally don't understand what it is you're getting at. Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage. Therefore it is still common for an application developer to "worry about salts" even if just for…

> I literally don't understand what it is you're getting at. I truly hope this will help then: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass... "Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you. > Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in…

> 3DES is a block cipher. MD5 is a crytographic hash.

3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar.

> Neither of them are password hashes.

25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years.

But no doubt you'd playing silly word games, and are going with your own definition of "password hash" that includes or excludes different hashing algorithms as it is convenient for you. I won't get drawn into that.

> What you're describing is closer to a "pepper".

What you're doing is called being "condescending." You know full well from my posts above that I am familiar with salt/peppering/hashing, and the different technologies involved. So linking to 101 tutorials and definitions of basic terms is only intended to aggravate.

Post reply on HN