How to Safely Store Your Users' Passwords in 2016

Post by dogweather » Mon, Feb 22, 2016, 8:18 PM UTC

CM30 wrote: post #233

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

Post by JadeNB » Tue, Feb 23, 2016, 3:42 AM UTC

Vendan wrote: post #310

JadeNB wrote: post #286

Earlier quoted context omitted.

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

Post by ngrilly » Tue, Feb 23, 2016, 4:48 PM UTC

jayeshsalvi wrote: post #113

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

Post by balls187 » Tue, Feb 23, 2016, 7:42 PM UTC

ngrilly wrote: post #314

balls187 wrote: post #305

Earlier quoted context omitted.

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…

> If you don't require privileged elevation What do you mean by privileged elevation (I'm talking in the context of a web app)? > just using an email address and send "magic links" + persistent (but expiring) sessions Do you mean something similar to what Medium does? https://medium.com/the-story/signing-in-to-medium-by-email-a... I like it too. But what about delays in receiving emails (when I suggested this approac…

Post by ngrilly » Tue, Feb 23, 2016, 9:07 PM UTC

balls187 wrote: post #317

ngrilly wrote: post #314

Earlier quoted context omitted.

> If you don't require privileged elevation What do you mean by privileged elevation (I'm talking in the context of a web app)? > just using an email address and send "magic links" + persistent (but expiring) sessions Do you mean something similar to what Medium does? https://medium.com/the-story/signing-in-to-medium-by-email-a... I like it too. But what about delays in receiving emails (when I suggested this approac…

> What do you mean by privileged elevation (I'm talking in the context of a web app)? For example, prior to changing account settings, reauthenticate the users, regardless if they have a valid session. > I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)? Combo of email & SMS. As Bruce Schneier has written, security is usually a tr…