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

231–240 of 321 posts

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

#231

Post by seanp2k2 »

sarciszewski wrote: post #92
Joeri wrote: post #88

Earlier quoted context omitted.

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…

The blog post that HN is reading is served by PHP-FPM + nginx, without any extra special features to handle the load of an unexpected "oh hey we made it to the front page of HN". It's also hosted on a relatively cheap VPS.

Considering the other article from HN today about Stack Overflow being able to handle their top-100 global Alexa rank traffic with one physical web front end, I'm impressed but not that impressed. PHP has been popular for a long time and lots of smart people have figured out how to make it pretty quick.

For things like blog posts, I'm sad that Movable Type fell out of favor. The pattern of using dynamic server pages to edit blog posts and generate static files for your viewers just makes so much sense to me. Then again, these days we can host our single-page JS front-ends on S3 + CloudFront and hook them up to API gateway and Lambda / Beanstalk talking to RDS and "not have any servers" :)

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

#232

Post by herbst »

manojlds wrote: post #192
herbst wrote: post #77

Earlier quoted context omitted.

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.

Simpler and way much more reasonable.

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

#233

Post by CM30 »

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 about sites where the users don't particularly likely said providers? Not everyone uses Facebook or Google or Twitter after all, and a lot more would rather use an anonymous disposable account than one tied to an existing identity.

There's also the fact said systems seem to be a nice target for spammers. They're popular, so they're often attacked. And because they're often attacked, their anti spam defences don't usually last very long. So any spammer now has a nice way to get an account on near enough any site they like, while with a standalone system, they'd at least have to tailor their attacks to the site in question.

There's also the fact it silos much of the internet (or at least user information) within the systems of a few large providers, which gives a significant amount of control to said providers.

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

#235

Post by technion »

cm2187 wrote: post #234

What I find frustrating is the lack of availability of most of these algorithms for the most common platforms (.net, php, java). The author recommendation seems to be driven by availability, not the algorithms own merits.

It wasn't long back, trying to use bcrypt in PHP was an exercise in futility.

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

#236

Post by roel_v »

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…

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

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

#237

Post by tokenizerrr »

darkstar999 wrote: post #157
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…

Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure. We live in an age where this should be unacceptable. Why aren't there financial security laws yet?

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

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

#238

Post by melicerte »

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

That's an interesting point indeed. When you are fired from your job, you don't often have the time to connect to all our accounts based on your email address to change it. Just checked their FAQ[1] but this does not seems to be covered. Any clue someone?

[1] at the bottom of this page: https://medium.com/the-story/signing-in-to-medium-by-email-a...

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

#239

Post by tokenizerrr »

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 just don't want to trust closed-source code to manage passwords

KeePass? It's great, and open source.

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

#240

Post by tokenizerrr »

sarciszewski wrote: post #226
dheera wrote: post #224

Earlier quoted context omitted.

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.

Password managers are more secure. Here you just need the master password, with password managers you need the master password and the database file.

Still, a lot better than password re-use.

Post reply on HN