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

191–200 of 321 posts

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

#191

Post by tptacek »

jimktrains2 wrote: post #171
tptacek wrote: post #132

Earlier quoted context omitted.

In exactly the same way as any other password hash is cracked.

By iterating over all passwords? That seems like the definition of a good password storage if that's the only way! I mean, you can make the same complaint against anything; it's meaningless by definition. Sure, public-private pairs are more difficult (to impossible) to brute force once they're so long, but srp, bcrypt, pbkdf2 &c are pretty good when you want/need a password. Srp being superior in that your secret nev…

I'm not following you. The whole point of a password hash is to (1) admit only that one brute-force attack, and then (2) to slow that attack down as much as possible.

SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total design freedom.

You can combine PAKEs and password hash concepts. But for the purposes of password storage, SRP isn't buying you anything (except for a bunch of possible crypto bugs that will gameover your project).

SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."

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

#192

Post by manojlds »

herbst wrote: post #77
rms_returns wrote: post #72

Earlier quoted context omitted.

I once had to call my bank a few years ago to disable my debit card. The reason was that I inserted it in an ATM and the ATM had chosen that exact moment to malfunction and shut down! The operator on the line asked me a ton of questions starting from my user-id (but not password), date of birth, full name, father's name, place of birth, type of account and many others that I don't remember now. Only after I correctly…

My bank always asks me for: Birthday, Address and last time i got how much money. The first 2 details can be easy (in my country there is a website which shows this for most people who dont know how to stop them), the third one can be easy if you stalk me a day or two. But if i tell them to not make it that easy, i cant manage my shit over the phone anymore :/

I have a telephonic pin for my account that I use.

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

#193

Post by [deleted] »

herbst wrote: post #77
rms_returns wrote: post #72

Earlier quoted context omitted.

I once had to call my bank a few years ago to disable my debit card. The reason was that I inserted it in an ATM and the ATM had chosen that exact moment to malfunction and shut down! The operator on the line asked me a ton of questions starting from my user-id (but not password), date of birth, full name, father's name, place of birth, type of account and many others that I don't remember now. Only after I correctly…

My bank always asks me for: Birthday, Address and last time i got how much money. The first 2 details can be easy (in my country there is a website which shows this for most people who dont know how to stop them), the third one can be easy if you stalk me a day or two. But if i tell them to not make it that easy, i cant manage my shit over the phone anymore :/

[deleted]

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

#194

Post by [deleted] »

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?

[deleted]

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

#195

Post by [deleted] »

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?

[deleted]

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

#196

Post by [deleted] »

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?

[deleted]

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

#197

Post by stronglikedan »

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.

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

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

#198

Post by gnaritas »

alextgordon wrote: post #119
jayeshsalvi wrote: post #113

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

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)

> That's horrible, means you can't use it with incognito mode

No it doesn't.

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

#199

Post by sarciszewski »

dogweather wrote: post #185

I believe that the safest way is not to save them. Instead, outsource this to a few select OAuth providers which you and your customers are willing to trust.

What do you do if your name is Dread Pirate Rogers and the set of OAuth providers you and your customers trust is "None"?

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

#200

Post by mkj »

VincentEvans wrote: post #156
cpitman wrote: post #154

Earlier quoted context omitted.

The more standard way to migrate passwords/authentication schemes is to do it on login. So if you want to switch to scrypt from some other format, wait for them to login, check their password via the old method, then rehash the password with the new method. Store in the database which method was used. If you're switching to a non-password based system like OAuth, make users link their accounts after logging in with t…

Thank you for your reply. Interesting you mention intercepting users passwords. Our system already went through a similar transition years ago - when we had to migrate away from NDS (Novell), since we abandoned that technology. In NDS we did not have access to hashes. We ended up having to "MTM" the passwords in opur web app to intercept them before they are sent to NDS and after a successful login store them in the…

> But the question still stands - is asymmetric encryption strong and secure enough to take place of hashing, assuming the private key is secured?

It should be (though it's a big "assuming"). Being able to quickly move away from an older less secure hashing scheme rather than waiting for users to log in could be a security advantage too.

Post reply on HN