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

301–310 of 321 posts

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

#301

Post by JadeNB »

Domenic_S wrote: post #292
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…

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?

This is a good argument, but I'm not sure that I buy this. There are plenty of industries (I think of the cable and cell-phone industries, but I'm sure there are others) where it's just a given that the service will be crappy, even though one company that started to respect its customers could seemingly corner the market. (I'm not sure what are the results of T-Mobile's exercises in respecting its customers. Their unfortunate net-neutrality stance with Binge On means that it's not an unalloyed win to go with them.)

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

#302

Post by joepie91_ »

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?

It is indeed not correct. They are not functionally equivalent to their asynchronous equivalents at all - your entire event loop will be blocked for the full duration of the operation.

This may sound like "not a big deal", but even an operation that takes 1ms will cause noticeable lag at ~50 operations per second, and block everything approaching a thousand.

For emphasis: they block the entire event loop. Not a single request, not a single client, not a single operation or event. The entire application for every user everywhere.

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

#303

Post by Domenic_S »

JadeNB wrote: post #301
Domenic_S wrote: post #292

Earlier quoted context omitted.

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?

This is a good argument, but I'm not sure that I buy this. There are plenty of industries (I think of the cable and cell-phone industries, but I'm sure there are others) where it's just a given that the service will be crappy, even though one company that started to respect its customers could seemingly corner the market. (I'm not sure what are the results of T-Mobile's exercises in respecting its customers. Their un…

I get what you're saying, but credit cards are unique: the advantage credit card companies have over those other industries is that there is essentially no lock-in, and your old cards continue to work while you're in the process of switching eg your autopays over. It's a very switch-friendly industry.

Remember when you couldn't take your cell phone number with you and so pretty much nobody switched carriers? It was a massive pain. Now it's easier than ever to switch, except most people are locked into multi-year contracts. Switching friction = high, but not impossible. As you said, TMO is trying to compete here.

Cable has monopolies on towns, so there's 0 incentive. People couldn't switch even if they wanted to. I suppose there's satellite, but you'll still be paying the cable company for internet -- they get their pound of flesh no matter what. Switching friction = impossible.

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

#304

Post by JadeNB »

Domenic_S wrote: post #303
JadeNB wrote: post #301

Earlier quoted context omitted.

This is a good argument, but I'm not sure that I buy this. There are plenty of industries (I think of the cable and cell-phone industries, but I'm sure there are others) where it's just a given that the service will be crappy, even though one company that started to respect its customers could seemingly corner the market. (I'm not sure what are the results of T-Mobile's exercises in respecting its customers. Their un…

I get what you're saying, but credit cards are unique: the advantage credit card companies have over those other industries is that there is essentially no lock-in, and your old cards continue to work while you're in the process of switching eg your autopays over. It's a very switch-friendly industry. Remember when you couldn't take your cell phone number with you and so pretty much nobody switched carriers? It was a…

These are good points. My remark was off the cuff; it's clear that you've thought (or at least are thinking) about it much more deeply.

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

#305

Post by balls187 »

ngrilly wrote: post #115
balls187 wrote: post #65

Earlier quoted context omitted.

My point is simply if you can avoid storing user credentials, avoid storing their credentials. For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more…

I agree that it's better to avoid storing user credentials, but what do you suggest instead to authenticate the user?

If you don't require privileged elevation, then I'm a fan of just using an email address and send "magic links" + persistent (but expiring) sessions.

For mobile apps, I think using SMS and One-Time Passwords is sufficient as well.

You can also use a delegated auth system put in place by OAuth v2, or something like Google Accounts, Twitter, etc. Those services do get pushback, as not every uses Gmail (or likes to give any run of the mill app access to Google account data).

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

#306

Post by Nullabillity »

dagurp wrote: post #116
jayeshsalvi wrote: post #113

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

The only problem I see with that is when people change email addresses (maybe they were using their work email and change jobs).

Don't use your work/school/ISP/whatever email. Period.

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

#307

Post by sarciszewski »

darkstar999 wrote: post #280
tokenizerrr wrote: post #237

Earlier quoted context omitted.

Well, there's your problem. When dealing with passwords you don't want encryption. You want hashing.

Hashing is considered one-way encryption, no?

No, it's one-way cryptography, but it's not a form of encryption.

https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

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

#308

Post by sarciszewski »

majewsky wrote: post #296
sarciszewski wrote: post #289

Earlier quoted context omitted.

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

How would transforming it before sending it over the wire help here?

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

#309

Post by majewsky »

sarciszewski wrote: post #308
majewsky wrote: post #296

Earlier quoted context omitted.

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

How would transforming it before sending it over the wire help here?

Not at all. If I want to impersonate someone, I just have to act like them. The only protection is 2FA.

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

#310

Post by Vendan »

JadeNB wrote: post #286
mhw wrote: post #243

Earlier quoted context omitted.

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

note though, that this means you have a collection of hashes for the password that are each 3 characters or whatever long, which can be brute forced in essentially no time at all. Crack em all, lay them out according to what letters the hash is for, put it all together and you are done. Even just having 1 subset reduces your passwords security by that many letters, if not more (you can filter out dictionary guesses that don't match those letters and such)
Post reply on HN