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

201–210 of 321 posts

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

#201

Post by swang »

Zarel wrote: post #188
joepie91_ wrote: post #178

Earlier quoted context omitted.

More specifically, any functions that end in Sync should be avoided. Unfortunately a lot of people think that these functions are a simple way to "not have to deal with callbacks", which is not correct...

It's not correct? Is there any reason not to use the Sync functions if you're not writing a web server and don't particularly care for performance?

If it's your own thing, do whatever you want. But the only thing sync should be used is to exec shell scripts in node.js. sync functions are bad otherwise in any kind of production environment.

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

#202

Post by nommm-nommm »

alextgordon wrote: post #119
jayeshsalvi wrote: post #113

By not storing them https://medium.com/the-story/signing-in-to-medium-by-email-a...

So there's no password option? That's horrible, means you can't use it with incognito mode (because you'd have to receive an email each time)

This is how Craigslist has done it for more than a decade. You can "make a account" with a username/password if you want but it isn't needed.

No issues with incognito mode.

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

#203

Post by swang »

NickNameNick wrote: post #190
lazyjones wrote: post #161

Earlier quoted context omitted.

> 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 can do the bcrypt() inside your (PostgreSQL) database and add an extra layer of security by not directly exposing the hash (or even the whole password table) to the web server process (i.e. write a password check SQL function and allow only calling it, no direct table/column access).

Congratulations, now there are plaintext passwords in your server logs... I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved t…

I don't see how moving to the web server would prevent that if you were logging passed req body or query parameters since they would be posted in plaintext (hopefully) over a https connection.

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

#204

Post by jsmeaton »

dogweather wrote: post #185

I believe that the safest way is not to save them. Instead, outsource this to a few select OAuth providers which you and your customers are willing to trust.

I agree for the majority of cases. There still exist classes of applications where you can't rely on personal accounts on social sites for auth. Anything that runs behind your firewall for instance. In my particular case, we run some "enterprise software" on behalf of our customers, whose users regularly don't even have a work email address. Our customers are certainly not going to want users to use their own personal addresses.

Most of this can be solved with SAML, but it requires all of these old enterprisey stacks to convert their auth systems to be SAML compatible.

In the long term though, I think SAML and OAuth will be more prevalent than using passwords everywhere.

Are there any OAuth providers established that simply provide email addresses? I feel there's definitely room for a company to setup an OAuth provider that doesn't do anything except provide identity, rather than relying on personal information harvester companies (FB, Google, etc). The hard part would be getting onto the approved OAuth providers list of all the sites that users want access to.

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

#205

Post by rtpg »

scruple wrote: post #187
CydeWeys wrote: post #182

Earlier quoted context omitted.

It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.

PCI compliance is pretty interesting. It's been many years since I worked in an e-commerce shop but I seem to remember that it even described physical security layers i.e., dictating the placement of door hinges to server rooms.

Goes to show that when money is at stake for the stakeholders then things get done.

I don't think banks actually care about individual user login security too much. Credit Cards reallllly suffer from security breaches though

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

#206

Post by dheera »

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…

I also hate the stupid security questions used to identify you which they always claim "add security". In almost all cases they decrease security.

Where did you spend your honeymoon? What was the name of your first pet? What is the name of the street where you grew up?

For any given person, a LOT of people know the answer to these kind of questions.

Also, I hate it when people use date of birth to verify identity. Medical people love doing this. Um, just check the person's Facebook and see when everyone wishes them a happy birthday, then go access their medical records?

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

#207

Post by paulddraper »

dheera wrote: post #206
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…

I also hate the stupid security questions used to identify you which they always claim "add security". In almost all cases they decrease security. Where did you spend your honeymoon? What was the name of your first pet? What is the name of the street where you grew up? For any given person, a LOT of people know the answer to these kind of questions. Also, I hate it when people use date of birth to verify identity. Me…

I'm not saying I disagree, but how would you verify identity over the phone?

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

#208

Post by jsmeaton »

xs wrote: post #160

Lame title. Story talks about storing password hashes and not passwords. I'm still looking for a solution to storing actual user passwords. Scenario: All laptops in the company have a unique local administrator password. How do I manage this effectively as a domain admin?

Use a password manager of some kind. Lastpass is nice, and has an enterprise component that lets you share passwords with co-workers or teams.

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

#209

Post by noisy_boy »

paulddraper wrote: post #207
dheera wrote: post #206

Earlier quoted context omitted.

I also hate the stupid security questions used to identify you which they always claim "add security". In almost all cases they decrease security. Where did you spend your honeymoon? What was the name of your first pet? What is the name of the street where you grew up? For any given person, a LOT of people know the answer to these kind of questions. Also, I hate it when people use date of birth to verify identity. Me…

I'm not saying I disagree, but how would you verify identity over the phone?

By allowing people to set their own questions and answers instead of a) using a pre-defined list of questions b) forming questions from information about the customer that friends/acquaintances usually know or information that can be found via a Google search.

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

#210

Post by joveian »

sarciszewski wrote: post #140
Strilanc wrote: post #138

Earlier quoted context omitted.

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient. Not sure how I feel about it.

I feel that this is needlessly dangerous, personally. How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.

The salt could be created from the username (possibly with a standardize form step for case insensitively and maybe also including a site salt).

On mobile devices client side hashing could affect battery life. If done with javascript, then login won't work without javascript enabled. Also, a work factor that doesn't slow down the slowest devices that a user might use could provide much less protection than desired, although the server could also do some work.

Post reply on HN