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

291–300 of 321 posts

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

#291

Post by soft_dev_person »

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

A lot of people don't really know their own email address, then. When based on their name, they might write both with capitalization and without depending on mood...

We lower-case all e-mails in our systems. I'll let you know when we hit a system that actually treats it case-sensitive.

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

#292

Post by Domenic_S »

JadeNB wrote: post #282
rtpg wrote: post #205

Earlier quoted context omitted.

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…

I don't know if that's true. Say we lived in a world where those regulations didn't exist and the fraud risk was on par with what it is today. If one bank introduced their own fraud protection program, wouldn't they basically capture 90% of the market overnight?

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

#293

Post by oliwarner »

sarciszewski wrote: post #287
oliwarner wrote: post #281

Earlier quoted context omitted.

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

Your first paragraph is like saying using email is forcing somebody to use one of a "limited set of companies". It's nonsense. Again, if they don't like what's on offer they can host their own, just like email!. They can hire a company like yours to host their credentials with as many layers of security as they want. The user has ultimate choice.

Secondly, every website on the Internet is potentially an OAuth provider.

Not to mention that I have —on multiple occasions here— suggested that websites that consume OAuth should also provide it (like Stack Exchange).

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

#294

Post by majewsky »

roel_v wrote: post #236
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…

"Medical people love doing this" Tangential to the actual issue, but in that field it's to prevent patient mixups, not to defend against malicious attackers.

I once saw a report about two persons having the same name, same birthday, and same birthplace. It really fucks up a lot of administrative databases.

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

#295

Post by majewsky »

LordKano wrote: post #262
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…

Back from 2009-2010, I did work as a web developer on an ecommerce site. A month or so in, I discovered that they kept all of the user password unencrypted in a database. I went to my boss and explained that we can't do that. It's inviting exploitation. He responded to me that we had to keep them in plain text, in the database so that we could send them to users who forgot. If they can't login, they won't order produ…

Unhashed passwords don't get you pwned. They only become a problem after you've been pwned.

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

#296

Post by majewsky »

sarciszewski wrote: post #289
technion wrote: post #228

Earlier quoted context omitted.

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"?

"Shoulder surfing" refers to people extracting personal information, such as credentials, from your computer by just looking over your shoulder while you're typing them in or displaying them.

Precisely the reason why password input fields usually display replacement characters instead of actual characters (or nothing at all if you're on a Unix terminal).

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

#297

Post by Klathmon »

novaleaf wrote: post #278
dsp1234 wrote: post #266

Earlier quoted context omitted.

but I'd think the point of a js KDF is to run on the client, not the server. bcrypt is used on the server (node.js) to hash a user's password before storing it in the database. Then later, when a login is done, the password from the login is checked against the stored hash to see if the match (and by implication, that the original passwords are the same). So the usage is mostly on the server as expecting a client suc…

right, but running bcrypt on a server, why run a pure javascript version? Why not the C-compiled version? So to me the logic behind a pure js version is one that can run on the client too. It actually sounds interesting, as it could improve password security! But it's just too slow. In my case, I ended up sha512'ing the password client-side, and use that as the "password" sent to the server. If there were a native KD…

In our case, we use the pure-js version during development.

Some windows developers have issues compiling native modules, and it was easier to try the native plugin, if it fails fallback to the pure-js version with an identical API during development. That way we get the ease of development with pure-js, and the production speed of the native module.

Also there is the ability to run client side (mesh networks with webRTC), and the ability to run this on architectures other than x86 where the native version won't compile.

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

#298

Post by lostmypassword2 »

JadeNB wrote: post #282
rtpg wrote: post #205

Earlier quoted context omitted.

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…

What law are you talking about? PCI-DSS is required by the card companies and run an organization called the "Payment Card Industry Security Standards Council". It's self-governed essentially. It's not federal law

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

#299

Post by Vendan »

matthewowen wrote: post #163
stronglikedan wrote: post #133

Earlier quoted context omitted.

> Why is it telling me I created a new account instead of logging me into my existing account? > Email addresses on Medium are case-sensitive. Wow. Is there ever any possible benefit to this? (Serious question)

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.

Note that the local mailbox portion MUST BE treated as case sensitive in the context of the SMTP protocol and such, but it is up to the mail host to actually define the semantics of the local part. Non-case sensitive mailboxes is not prohibited anywhere in the spec, what you are referring to is there to prevent the local portion of the address from being changed when passed through a relay.

"the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."

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

#300

Post by JadeNB »

lostmypassword2 wrote: post #298
JadeNB wrote: post #282

Earlier quoted context omitted.

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

What law are you talking about? PCI-DSS is required by the card companies and run an organization called the "Payment Card Industry Security Standards Council". It's self-governed essentially. It's not federal law

I had always assumed that it was a matter of law, rather than self governance. I stand corrected.
Post reply on HN