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

281–290 of 321 posts

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

#281

Post by oliwarner »

sarciszewski wrote: post #270
oliwarner wrote: post #264

Earlier quoted context omitted.

I did answer. They can host their own. I don't understand why they would trust over a dedicated authentication storage place but that's their choice. And yes, there is also every possibility to offer direct credentials, per the Stack Exchange model (they host their own oAuth server and allow simple registrations).

> I don't understand why they would trust over a dedicated authentication storage place but that's their choice. What if happens to be a security engineer, and happens to be Silk Road 13? The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.

Again. The user picks who they authenticate with. You (the site owner) get no say in the matter. You aren't outsourcing it to any one company.

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

#282

Post by JadeNB »

rtpg wrote: post #205
scruple wrote: post #187

Earlier quoted context omitted.

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

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

But the only reason that banks care so much about credit-card security breaches is that the law forces them to do so. If the law didn't make credit card fraud the bank's responsibility, then they'd be just as lackluster about preventing it as they currently are about securing login credentials.

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

#284

Post by timv »

owenmarshall wrote: post #267
timv wrote: post #175

Earlier quoted context omitted.

> scrypt(password,salt,work_factor) on the server is plenty hard to attack For a large enough work_factor. In practice "large enough" is usually interpreted to mean "something that seems safe without being so large that I need to buy lots more servers" The argument (which I'm interested in, but not yet sold on) is that moving the scrypt to the client allows you to pump up the work_factor even higher than you would ha…

After thinking about it more the concept is interesting, but the main fear I have is that doing it in a web browser with JS is next to impossible to secure. Maybe if vendors got on board... In general though, pushing auth down to clients in Javascript makes my skin crawl. You're one XSS away from having an attacker no-op your scrypt and return SHA256("secret-attacker-password") on registration. The logical follow-up…

The proposals I've see have always had the initial scrypt be done on the server.

The DOS risk on registration can be mitigated more easily than the login one. e.g. Rate limiting new registrations will often be more palatable than limiting logins, or you can require "email validation" before you set the first password. And, not every application allows self registration.

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

#285

Post by VincentEvans »

VincentEvans wrote: post #276
Vintila wrote: post #220

Earlier quoted context omitted.

I'd been considering something similar, never really made a PoC though. How about this: User provides their public key when they signup. To authenticate, server produces a nonce and sends to the client, client signs the nonce with private key and sends the result, server verifies signature with public key.

Interesting thought, i need to think about it - i will and write a reply when i have a little more time than i do at present. What are your reasons to hold on to the password?

Upon further consideration, this pretty much describes a an authentication method based on a client certificate. Unless i am missing something - i am not sure how to apply this to our problem space. We have traditional type of users who are used to username/password authentication. Solutions that we consider have to build on that as a fundamental model.

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

#286

Post by JadeNB »

mhw wrote: post #243
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…

Bear in mind that giving the password over the phone has a different threat model to sending the password over a TLS-secured connection from your browser to a bank-run web server. Specifically there is a human in the call centre who is transcribing what you say. Using a partial password (give me letters X, Y and Z) is a way of mitigating the risk of call centre staff being able to harvest meaningful amounts of securi…

> This does mean that you need to be able to check subsets of the characters in the password, which rules out hashing the whole password in this case.

As you implicitly point out, however, it doesn't require any portion of the password ever to be visible to the call-centre employee; one can just supplement an individual hash by a collection of hashes of appropriate character subsets, and then (say) randomly pick among the available subsets.

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

#287

Post by sarciszewski »

oliwarner wrote: post #281
sarciszewski wrote: post #270

Earlier quoted context omitted.

> I don't understand why they would trust over a dedicated authentication storage place but that's their choice. What if happens to be a security engineer, and happens to be Silk Road 13? The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.

Again. The user picks who they authenticate with. You (the site owner) get no say in the matter. You aren't outsourcing it to any one company.

No, you're saying "which of this limited set of companies are you going to authenticate with" instead. If you don't want to be guilty of taking users' agency away from their own trust decisions, you need to do one of two things:

1. Let every website on the Internet potentially be an OAuth provider.

2. Make OAuth optional.

If you follow option #2, then this article is still relevant because you need to handle passwords securely.

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

#288

Post by alextgordon »

Kiro wrote: post #134
alextgordon wrote: post #119

Earlier quoted context omitted.

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)

You can use the link in incognito. Why wouldn't you?

Because every time you open the site you'd have to receive an email. vs just letting 1password, browser, etc enter the password.

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

#289

Post by sarciszewski »

technion wrote: post #228
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 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.

"shoulder surf protection"?

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

#290

Post by jtheory »

dheera wrote: post #257
pjungwir wrote: post #221

Earlier quoted context omitted.

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.

How many common "first instruments" are there for kids? Maybe 5? There's a pretty good chance you'll get it right without doing any research whatsoever.

It's not quite as bad as asking "what species was your first pet?" but not much better.

This is the real problem with security questions; the answer space is often so very small, and can be narrowed down even further with a little research.

Questions like "what was the first name of (your maternal grandmother, your first best friend, etc.)" are very common -- well, there are stats on most popular first names of given generations in different places. If you know what country the person is in, you can make a good guess at these.

Post reply on HN