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

251–260 of 321 posts

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

#251

Post by oliwarner »

sarciszewski wrote: post #250
oliwarner wrote: post #249

Disappointed that the first solution isn't: Let somebody else do it. I know this doesn't apply to banking, etc but 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me. Please pick a secure implementation of oAuth2 and let people store their credentials wherever the hell they want to. I'm bored of getting hits from "Have I been pwned?"

This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then? > 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).

You don't integrate with a provider. You implement the protocol and let your users supply a URL. Layering on popular alternatives (Facebook, Google, etc) help, but use the Stack Exchange model. Let users do what they want to do.

That way users can be their own oAuth providers if they want.

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

#252

Post by zaroth »

VincentEvans wrote: post #150

Serious question: What about using a Public/Private key encryption to store the password? - Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed. - When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt. - When user attempts to authenticate - the…

This only works for deterministic encryption like "textbook RSA", not for any semantically secure encryption, which would produce different ciphertext each time you run it.

I would worry about trying to dual-purpose the encryption like this. If you feel like you must have a way to get the plaintext password back, which BTW you really really do NOT want that liability, but anyway, the safer choice would be to use a semantically secure encryption of the password, and then ALSO hash the password using the current best practices. Use the hash for now to authenticate users, keep the ciphertext if you must, but you'll probably regret it.

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

#253

Post by novaleaf »

minitech wrote: post #219
novaleaf wrote: post #165

Earlier quoted context omitted.

wow that's some serious downvotes. Why? a 1 second KDF function on a GPU will take upwards of a minute in javascript ... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.

I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well as far as password storage goes, so a pure JavaScript bcrypt is bad mostly because it’s blocking on Node and not because it’s too slow to be useful. Please don’t pull numbers out of nowhere.

when I was figuring out password security I did some tests. on my phone (a galaxy s3) I got about a 40x slowdown of pbkdf2 versus an x86 server running a compiled version (C I assume). I suppose running the js version on a server might give a better runtime, but I'd think the point of a js KDF is to run on the client, not the server.

edit: and I'd assume a GPU version would be faster.....

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

#254

Post by sarciszewski »

oliwarner wrote: post #251
sarciszewski wrote: post #250

Earlier quoted context omitted.

This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then? > 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).

You don't integrate with a provider. You implement the protocol and let your users supply a URL. Layering on popular alternatives (Facebook, Google, etc) help, but use the Stack Exchange model. Let users do what they want to do. That way users can be their own oAuth providers if they want.

My question was: "What if your users don't trust any of the existing providers on Earth?"

It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust.

Offer OAuth2 as an alternative to passwords: Great move.

Only offer OAuth2 and don't let people create an account: Questionable.

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

#255

Post by novaleaf »

Klathmon wrote: post #167
novaleaf wrote: post #165

Earlier quoted context omitted.

wow that's some serious downvotes. Why? a 1 second KDF function on a GPU will take upwards of a minute in javascript ... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.

where are you getting those numbers from?

my own testing. maybe not a 1 sec to 1 minute factor though. see my other reply in this thread a few seconds ago.

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

#256

Post by [deleted] »

zaroth wrote: post #252
VincentEvans wrote: post #150

Serious question: What about using a Public/Private key encryption to store the password? - Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed. - When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt. - When user attempts to authenticate - the…

This only works for deterministic encryption like "textbook RSA", not for any semantically secure encryption, which would produce different ciphertext each time you run it. I would worry about trying to dual-purpose the encryption like this. If you feel like you must have a way to get the plaintext password back, which BTW you really really do NOT want that liability, but anyway, the safer choice would be to use a se…

[deleted]

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

#257

Post by dheera »

pjungwir wrote: post #221
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 loathe security questions too, but those aren't even that bad! My credit union's default security question is "What was your first musical instrument?" I wonder how many guesses you get?? I always answer these questions with a long string of random characters.

LOL, check their Facebook pictures and see if they are playing an instrument in any of them. Most people don't play more than 1 instrument, so it's probably their first.

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

#258

Post by dheera »

equivrel wrote: post #242
dheera wrote: post #224

Earlier quoted context omitted.

Not really. I don't oppose using a master password, which I don't use anywhere directly or store on disk anywhere. I just don't want to trust closed-source code to manage passwords, and want to be able to generate the password to anything from anywhere without having to carry around an encrypted table of stored passwords. In this case, I implement it myself, with the help of some common open-source Python libraries.

Have a look at pass [1], it's a minimalist tool in bash that is so simple you can easily make adjustments to it yourself. The codebase is very small so it is easy to audit. The principle is that your password are encrypted with your public key. You can then use git to keep running copies of your encrypted passwords on many devices. [1] - https://www.passwordstore.org/

Thanks! This is interesting.

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

#259

Post by mnw21cam »

Strilanc wrote: post #138
sarciszewski wrote: post #123

Earlier quoted context omitted.

How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…

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.

Since the hash is derived purely from the password, it demonstrably does not have any more entropy than the password.

Before you mention the salt - the salt is only useful if it if available. The client needs to know the salt in order to perform the calculation, therefore your attacker will also know the salt, so that doesn't count as entropy in the hash, either.

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

#260

Post by ArtDev »

collinmanderson wrote: post #248
darkstar999 wrote: post #157

Earlier quoted context omitted.

Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure. We live in an age where this should be unacceptable. Why aren't there financial security laws yet?

I hear credit unions are not regulated as well as banks, so even if there are laws for banks, the credit unions don't necessarily have to comply. Credit union security will probably always lag behind banks. :(

I don't think that is true. Source?

Furthermore, credit unions can't make risky bets that could put them under. The money you deposit goes out as loans to other people.

I avoid banks like the plague. Too shady for me, never again.

Post reply on HN