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

221–230 of 321 posts

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

#221

Post by pjungwir »

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

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

#222

Post by sarciszewski »

dheera wrote: post #217
ecoffey wrote: post #215

Earlier quoted context omitted.

You can still have the question. But my answer is a random 32 character string of alphanumerics :)

I algorithmically generate the answers to the security questions with: answer = PBKDF2(hmacsha1, password + question, "", 100000, 16) This is also incidentally the basis for how I generate unique passwords for every service except banks, communication, and other sensitive things. I want a different password on every website and don't want to trust any password-remembering software I didn't write. The same function wo…

This is morally equivalent to using a password manager to encrypt your passwords with a "master password". :)

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

#223

Post by MildlySerious »

stronglikedan wrote: post #197
matthewowen wrote: post #163

Earlier quoted context omitted.

The local mailbox portion (bit before the "@") of email addresses is case sensitive. In practice, most email providers don't actually honor that, and so in practice it's a bad move. It is technically correct though.

Hmmm...right you are. Thanks. I guess I never thought to look that up. Likely due to the common way being so pervasive. > The local-part of a mailbox MUST BE treated as case sensitive. [0] [0] https://www.ietf.org/rfc/rfc2821.txt

As for handling this in the real world, the approach I like best is to store email addresses the way they are entered, but create an index on the lowercase version for lookup and uniqueness checks.

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

#224

Post by dheera »

sarciszewski wrote: post #222
dheera wrote: post #217

Earlier quoted context omitted.

I algorithmically generate the answers to the security questions with: answer = PBKDF2(hmacsha1, password + question, "", 100000, 16) This is also incidentally the basis for how I generate unique passwords for every service except banks, communication, and other sensitive things. I want a different password on every website and don't want to trust any password-remembering software I didn't write. The same function wo…

This is morally equivalent to using a password manager to encrypt your passwords with a "master password". :)

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.

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

#225

Post by minitech »

Someone1234 wrote: post #25
tptacek wrote: post #13

Earlier quoted context omitted.

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

> If … your system doesn't use randomly generated per user salts

… then you’ve already lost, constant-time comparison or not.

Also, rainbow tables are obsolete.

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

#226

Post by sarciszewski »

dheera wrote: post #224
sarciszewski wrote: post #222

Earlier quoted context omitted.

This is morally equivalent to using a password manager to encrypt your passwords with a "master password". :)

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.

I did say "morally equivalent" rather than "technologically equivalent".

By that, I mean the overall security of your password scheme is analogous to what people get out of a password manager.

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

#227

Post by [deleted] »

AstralStorm wrote: post #149
sinatra wrote: post #145

Earlier quoted context omitted.

Yes, now it's correct.

And still invalid. Are you assuming that collisions against SHA256(bcrypt(p)) are harder than SHA256(p), right? Any math to prove that? Otherwise, you're relying on the user side to properly safeguard bcrypted password. That is often wrong. You cannot store any kind of transformed password anywhere, or it's no longer a password, but a token. Yes, those "Remember me" things transform passwords into tokens. Tokens can…

[deleted]

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

#228

Post by technion »

sarciszewski wrote: post #123
sinatra wrote: post #118

From previous discussions about this topic, I had noted down the following best practices: Passwords should be scrypt'ed on client, and then, the server should generate a SHA256 hash of the scrypt'ed hash and store that in DB. - Running CPU & memory heavy scrypt hashing on the client side will allow us to use bigger hashing work-loads. - EDIT: Removing the MITM point, because as many said, that's the job of TLS anywa…

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 don't hate the idea of putting this piece:

    base64_encode(hash('sha384', $password, true))
In client side JavaScript. I've seen my own passwords scroll in front of my eyes when debugging servers and reading POST variables. It's a minor level of shoulder surf protection before it hits the proper hash on the server.

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

#230

Post by seanp2k2 »

Joeri wrote: post #88
herbst wrote: post #79

Earlier quoted context omitted.

Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.

PHP is usually deployed in a FastCGI multiprocess setup, so the server will keep handling requests on the other processes while the hashing process is blocked. I wonder whether threading really saves you, given that there are only so many cores in a system and password hashing is CPU heavy. Naively it seems a DoS would involve sending as many parallel requests as there are cores, which is not a lot and can easily be…

Even with mod_php you get 1 per fork with the prefork mpm, so this wouldn't even stop some Apache 2.2 box with php4 configured 10 years ago from accepting new connections.
Post reply on HN