How to Safely Store Your Users' Passwords in 2016

https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016

by antitamper • 10 years ago

479 295 10 years ago

pbreit• 10 years ago

Assuming this is legit (seems like it), mega bonus points for walking through examples on the various platforms/languages.

josefdlange• 10 years ago

Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison?

Is there something obvious I'm missing here?

bradleyjg• 10 years ago

I'm not a python person but it is probably a constant time comparison. If you compare things in such a way that the time it takes to complete increases with increasing prefix match than timing attacks are possible to recover the secret.

herge• 10 years ago

== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack.

hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.

Retric• 10 years ago

I don't think that's an issue when your comparing salted passwords. AKA F('Passsword') = Hash('Passsword' xor 'some value') = "123456"

F("value") > "123455" which is close, but that does not let you get a 'better' guess.

PS: Assuming the Salt is hidden, and the Hash is secure.

tptacek9• 10 years ago

Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.

wolfwyrd• 10 years ago

hmac.compare_digest is constant time whereas == will return as soon as a mismatch is found. The difference in return time can be measured. The key phrase is a Timing Attack[0].

[0]https://en.wikipedia.org/wiki/Timing_attack

privong• 10 years ago

For anyone who reads the comments before clicking the article, the subject is storing your users' passwords, not managing your passwords for a variety of services. I had interpreted it as the latter. A better title might be "How to Safely Store Your Users' Passwords in 2016".

(Title is currently: "How to Safely Store a Password in 2016")

bigbadgoose• 10 years ago

great, thanks. because i was about to reply with "on a piece of paper in the same place you store your diamonds"

TeMPOraL2• 10 years ago

I'm starting to think that if you're a security-conscious person and understand what's at stake, then the best solution for you would be to simply memorize it. Your mind is the only place from which an attacker can't steal your password without drugging you or beating you up until you give it out.

sarciszewski34• 10 years ago

You're right. I've updated the article title to avoid this ambiguity.

rehevkor53• 10 years ago

An even better title would be "How to Safely Generate and Use Password Hashes in 2016".

jimktrains24• 10 years ago

Or, we could move to not storing passwords at all, viz client certs and SRP.

tptacek9• 10 years ago

SRP still stores crackable password verifiers, and is tricky to implement safely.

jimktrains24• 10 years ago

Crackable in what way?

Of course the core of it could be upgraded, but the idea is sound. Sounds like you could say the same thing about using a DES-based hash. "Don't Hash! It's weak!" is throwing the baby out with the bath water.

rcconf• 10 years ago

If you're using node.js and you use these hashing methods, your entire server is going to pause for 0.5 seconds on a login because it runs on a single thread. Goodbye to all of your server performance.

You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

lukev• 10 years ago

I think this says more about node.js than it does about the proper way to secure a password.

StavrosK• 10 years ago

It definitely does, and I think that's the GP's point.

ARussell• 10 years ago

Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.

herbst5• 10 years ago

Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.

EGreg3• 10 years ago

It says both. The hashing is computationally expensive and Node runs in a single process (if we ignore workers). They could have made an implementation that yields and resumes after several ms. or you can spawn a worker and send it jobs.

abjorn• 10 years ago

The particular module being used in the article has async versions of those methods. He uses the synchronous versions in the example presumably for clarity/brevity.

phillipburch• 10 years ago

Or you could just use the async versions.... https://www.npmjs.com/package/bcrypt-nodejs

zwily3• 10 years ago

Does that library do the calculations in a thread pool, or is it just async on the main thread? If the latter (which seems mostly likely), then it won't matter.

dfischer• 10 years ago

Have any examples of how to properly handle it with node? Isn't it just the typical callback pattern?

warfangle3• 10 years ago

Incorrect; the first hashing method recommended uses a native CPP binding which launches a thread to execute both hashing and comparing.

Unfortunately, the example used for the bcrypt node module is the async form of hashing. That library exports both sync and async forms of hash/compare.

neals• 10 years ago

I find that using the original bcrypt node module is hard to build consistently, I often have trouble getting it built on various systems. I switched to bcryptJS which is a drop-in JS implementation.

Anybody here that knows if any of these is a valid replacement? https://nodejs.org/api/crypto.html

lazyjones• 10 years ago

You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

Or you can do the bcrypt() inside your (PostgreSQL) database and add an extra layer of security by not directly exposing the hash (or even the whole password table) to the web server process (i.e. write a password check SQL function and allow only calling it, no direct table/column access).

NickNameNick2• 10 years ago

Congratulations, now there are plaintext passwords in your server logs...

I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved the hashing process into the web server.

hellofunk2• 10 years ago

It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."

jobigoud• 10 years ago

Can you expand on this idea? What type of authentication method would replace it? (One that can't be directly linked to the person obviously).

jcrawfordor• 10 years ago

I'm optimistic for the use of physical tokens instead of passwords. In my work environment, a lot of authentication is based on physical token possession plus a password just as a guard against lost devices (password validated by the token, not by the service).

These kinds of systems aren't technically very complex but there hasn't been a lot of traction for them outside of corporate environments. The result is that they tend to be hyper-expensive, unfortunately. Standards like FIDO and the Yubikey are good first steps at pushing this into the consumer space, although they don't offer on-device PIN validation yet.

hellofunk2• 10 years ago

I remember an article about a month ago called "Google's Plans to Kill the Password." In any case, this is not a new problem and many smart people are trying to solve it because passwords suck.

I don't have a solution myself, but I hope there is one some day.

nickik2• 10 years ago

Look at what Fido is doing [1] they have new Standards called UAF (Universal Authentification Factor) and U2F (Universal Second Factor). The idea is that you use some kind of local authenticator and then you sign a challange from the server with a private key that is embeded in the authenticator. The Authenticator can be Fingerprint Sensor, a extern device that you authenticate with a password or it could highjack the OS level login.

New Samsung phones and Lenovo Laptops already support this on the fingerprint sencor but the true benefit is that you can have competition among local authenticators without the server having to change anything.

For legacy devices where you do not have any kind of local authenticator their could be local software that lets you enter passwords. Its already part of the standard that the server has a way to only allow some of the authenticators, based on certification. This would allow a bank to specifiy only devices manufactured by a specific company or that have passed some certification process.

Now some people of course say that fingerprint sensors are not very secure. That is true. It still increases security because the local authenticator will only sign the challenge if it is sent from the correct website/software (App Id) and in most cases the TLS Channel Id. UAF (and/or U2F) prevent far more common attacks at the cost of less security if an attacker actually steels your phone. You can combine UAF with U2F for additional security even if your phone/laptop is stolen.

This has been passed to the W3C and its hopped FIDO 2.0 will be an offical standard [2] [3].

Google, Github and Dropbox already support U2F. PayPal supports UAF (works on mobile). Both of these can also work with NFC and Bluetooth LE.

[1] https://fidoalliance.org/specifications/overview/

[2] https://fidoalliance.org/fido-alliance-announces-fido-authen...

[3] https://www.w3.org/Submission/2015/SUBM-fido-web-api-2015112...

raverbashing• 10 years ago

I think there's always going to be a need for an authentication mechanism that relies on user memory only

TorKlingberg• 10 years ago

For some reason the article completely fails to link to libsodium: https://download.libsodium.org/doc/

sarciszewski34• 10 years ago

For some reason the article completely fails to link to libsodium: https://download.libsodium.org/doc/

The "bindings for most programming languages" link goes to the libsodium documentation, but I'll add a link in more contexts.

daveloyall• 10 years ago

The article offers specific advice for Java-without-libsodium, but it offers no such specific advice for Java-with-libsodium.

There would appear to be three distinct Java bindings of libsodium.

AdmiralAsshat• 10 years ago

I had no idea that PBKDF2 had fallen so much in recent years. I still remember the 1Password team extolling its virtues five years ago:

https://blog.agilebits.com/2011/05/05/defending-against-crac...

sarciszewski34• 10 years ago

Correction: Scrypt actually uses PBKDF2 internally. (Previously said "scrypt is based on PBKDF2" but that's a loaded statment.)

PBKDF2 is an improvement over PBKDF1 (and other naive iterated hash constructions), but attacks got better and better defenses are called for.

cperciva2• 10 years ago

Scrypt is based on PBKDF2.

No, it really isn't.

tptacek9• 10 years ago

Questions like these are why I don't love the Password Hashing Competition.

In reality, PBKDF2 is fine. It's not the best thing you can use, in the same sense as AES is probably not the absolute best round-for-round, cycle-for-cycle cipher you can use, but it gets the job done.

The answer for "what password hash should I use" can accurately be summed as "put bcrypt, scrypt, Argon2, and PBKDF2 on a dartboard, and then throw a dart".

In 1PW's case, PBKDF2 is even more reasonable, because 1PW actually needed a KDF, and bcrypt is not an especially good KDF.

Freaky2• 10 years ago

base64_encode(hash('sha384', $password, true))
...
The above construction may invite theoretical concerns about entropy reduction (i.e. 72 characters of raw binary without any NUL bytes comes out to about 573 bits of possible entropy, but a SHA-384 hash outputs are clearly limited to 384 bits).

Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle. If you're brute-forcing search spaces this big you're no longer looking to recover a password, but find a collision.

sarciszewski34• 10 years ago

Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle.

This was added in response to a point that a couple people (or perhaps a convincing sockpuppeteer) raised and tried to use to decry the entire article. You're lucky to get 60 bits of information entropy in any given user's password, as is. The "theoretical weakening" here isn't a practical concern: "2^192 security" is still boring crypto.

pratnala• 10 years ago

Does Argon2 have an official website and repo or is it just the PHC repo?

sarciszewski34• 10 years ago

https://github.com/P-H-C/phc-winner-argon2 is the official repo.

balls1874• 10 years ago

"How to Safely Store a Password in 2016"

Don't. Unless it's 100% absolutely necessary.

If you must, continue reading on.

rehevkor53• 10 years ago

The article inaccurately describes generating a password hash & using it as "storing a password".

sarciszewski34• 10 years ago

The title has been corrected as of ~half an hour ago.

balls1874• 10 years ago

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 damage, than the data you were trying to secure.

For example, take your run of the mill online todo app. If an attacker got access to the all the todos, vs an attacker got access to the all the todos and all the user passwords (even if securely stored). What is more valuable to an attacker?

jordonias2• 10 years ago

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 confirmed it. This is an example of how to not handle passwords in 2016.

nostromo• 10 years ago

Name and shame.

rms_returns• 10 years ago

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 answered all these questions, did he start acting on my instructions.

herbst5• 10 years ago

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 :/

nkrisc2• 10 years ago

I don't know much about what sort of security compliance banks must implement, but surely that's in violation of something? What country?

jordonias2• 10 years ago

United States

jensvdh• 10 years ago

Plaintextoffenders!

aram• 10 years ago

I experienced this too many times with UK/US providers (e.g. Hostgator and Fasthosts). They often ask for server root password or email/password combo for the client portal, even after you verify account ownership.

Seems that they don't have any other way to grant the technicians access to the server/my account, which is absolutely ridiculous.

darkstar9992• 10 years ago

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?

CydeWeys• 10 years ago

It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.

tokenizerrr3• 10 years ago

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

collinmanderson• 10 years ago

I hear credit unions are not regulated as well as banks, so even if there are laws for banks, the credit unions don't necessarily have to comply. Credit union security will probably always lag behind banks. :(

dheera5• 10 years ago

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. Medical people love doing this. Um, just check the person's Facebook and see when everyone wishes them a happy birthday, then go access their medical records?

paulddraper• 10 years ago

I'm not saying I disagree, but how would you verify identity over the phone?

pjungwir2• 10 years ago

I loathe security questions too, but those aren't even that bad! My credit union's default security question is "What was your first musical instrument?" I wonder how many guesses you get?? I always answer these questions with a long string of random characters.

roel_v• 10 years ago

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

mhw• 10 years ago

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 security credentials. 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.

JadeNB6• 10 years ago

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 among the available subsets.

LordKano• 10 years ago

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

I have heard similar stories from other IT professionals. It's amazing that these operations aren't getting pwn3d twice a week.

majewsky4• 10 years ago

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

jtwebman• 10 years ago

Bad idea to use bcrypt.hashSync in Node.js. I hate that so many tutorials use that one instead of the correct bcrypt.hash with a callback. This is Node.js for that 200 ms where you are hashing that password nothing else runs, no requests, everything stops. Here is the correct way to use bcrypt in Node.js:

bcrypt.genSalt(10, function(err, salt) {

  if (err) return; //handle error

  bcrypt.hash(clearPassword, salt, function(err, hash) {

    if (err) return; //handle error

    // Store hash in your password DB.

  });

});

dsp12342• 10 years ago

Note that bcrypt.hash just calls bcrypt.hashSync anyways[0]. So there it's still going to stall exactly the same amount.

edit: Looks like it depends on which version you use.

'npm install bcrypt'[1] gives a version which supports true async usage (via V8 async callbacks in native code)

'npm install bcrypt-nodejs'[2] gives a pure JS version which I linked to. Which is the top search result for 'nodejs bcrypt'

[0] https://github.com/shaneGirish/bcrypt-nodejs/blob/master/bCr...

[1] https://www.npmjs.com/package/bcrypt

[2] https://www.npmjs.com/package/bcrypt-node

[3] https://www.google.com/search?q=nodejs+bcrypt

__abc• 10 years ago

BUT NODE.JS IS NON BLOCKING?!?@?!?!?!

Kidding.

novaleaf5• 10 years ago

lol at pure js KDF's

warfangle3• 10 years ago

And 'npm install bcrypt' is the package linked to from the article.

mbell• 10 years ago

The project from the article is https://github.com/ncb000gt/node.bcrypt.js

There, the encryption is handled asynchronously, the event loop is yielded while the calculations take place in a C extension.

joepie91_2• 10 years ago

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

Zarel• 10 years ago

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?

sarciszewski34• 10 years ago

https://paragonie.com/blog/2016/02/how-safely-store-password...

How does that look now?

serge2k• 10 years ago

PBKDF2 (nearly everyone except FIPS agrees this is the worst of the acceptable options)

is that true?

tptacek9• 10 years ago

Only in the most technical sense: cycle for cycle, PBKDF2 gets you the smallest amount of protection from that group of password hashes. PBKDF2 is still vastly better than non- password hashes like salted SHA.

joshreesjones• 10 years ago

You say that "PBKDF2 is still vastly better than non-password hashes like salted SHA", but is PBKDF2 (with >10,000 iterations using SHA512 and a random salt, for example) secure enough?

giancarlostoro• 10 years ago

I'm curious if any D developers care to share their approach to this?

sarciszewski34• 10 years ago

I'm part of the Paragon Initiative Enterprises team and have access to edit the blog. If you have any questions (AMA) or would like to suggest any additions, please let me know.

warrentr• 10 years ago

We really appreciate the post, thanks! Not a suggestion for this topic, but would love a future post on request signing in 2016 (think HMAC). In particular there are so many JSON REST APIs these days going over HTTPS that it's hard to determine best practices and what's overkill.

sarciszewski34• 10 years ago

Thanks for the suggestion, I'll put it on the list. :)

carlesfe• 10 years ago

Here's yesterday's discussion for the exact same post (maybe the duplicate search failed this time?)

https://news.ycombinator.com/item?id=11108481

intrasight• 10 years ago

Storing passwords is like storing credit card numbers - just don't do it

Justsignedup2• 10 years ago

Wish there was a site where it lists algorithms and gives a table, and an ability to compare it to x years ago:

algorith | fairly safe difficulty (all variables) | very safe difficulty without incurring too much performance cost.

pbkdf + sha1 | completely unsafe | completely unsafe

pbkdf + sha2 | 100000 | ...

pbkdf + sha256

bcrypt

scrypt

argon2

tptacek9• 10 years ago

PBKDF2-SHA1 is safe.

That's the problem with a chart like this. The gradation will go from "completely unsafe" salted hashes to "very much safe enough" with only marginal changes after that.

Another problem is that these functions are all parameterized, so the chart needs to capture the safety level at specific parameters.

sarciszewski34• 10 years ago

It would make for a good interactive "chart", perhaps. Whereby, as long as your sliders aren't all the way to the left, the chart is mostly green.

Justsignedup2• 10 years ago

My goal was to create a chart of:

algorith | a safe set of parameters | a VERY safe set of parameters but needs strong hardware

Maybe a 4th column of "unsafe if difficulty is below"

This could be something updated yearly or whatever to help people figure out what things they need to move towards. If they see that their currently used settings are below the unsafe line, they will know it's time to upgrade.

Example: I use PBKDF2-SHA1 at difficulty of 11k iterations. Is that number still within the "probably okay" list, or is that in the "I can hack any password on your list in 15 minutes"

latenightcoding• 10 years ago

Perl programmers should try this module: Crypt::ScryptKDF I have been using it for a while now

eCa• 10 years ago

And with DBIx::Class it is almost easier to do it right[1] than wrong.

[1] https://blog.afoolishmanifesto.com/posts/do-passwords-right/

jayeshsalvi• 10 years ago

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

dagurp• 10 years ago

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

melicerte3• 10 years ago

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

Nullabillity• 10 years ago

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

alextgordon2• 10 years ago

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)

Kiro• 10 years ago

You can use the link in incognito. Why wouldn't you?

gnaritas• 10 years ago

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

No it doesn't.

nommm-nommm• 10 years ago

This is how Craigslist has done it for more than a decade. You can "make a account" with a username/password if you want but it isn't needed.

No issues with incognito mode.

peterjlee• 10 years ago

I forget my passwords all the time so clicking on 'forgot password" is already my primary way to login on many sites I don't use often.

viraptor• 10 years ago

That works as long as the website has this functionality. One day you'll miss it... and end up writing to Bram Moolenaar, explaining why you forgot your password (http://www.vim.org/account/forgot_password.php)

stronglikedan2• 10 years ago

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)

matthewowen• 10 years ago

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.

wofo• 10 years ago

This is really awesome! I am going to use it for my next projects...

ngrilly6• 10 years ago

What about occasional delays in receiving the login email?

sinatra6• 10 years ago

From previous discussions about this topic, I had noted down the following best practices:

Passwords should be scrypt'ed on client, and then, the server should generate a SHA256 hash of the scrypt'ed hash and store that in DB.

- Running CPU & memory heavy scrypt hashing on the client side will allow us to use bigger hashing work-loads.

- EDIT: Removing the MITM point, because as many said, that's the job of TLS anyway.

- External brute force attackers will have to take the burden of heavy hashing. No DOSing through scrypt.

- Storing SHA256 hash instead of scrypt hash on DB means even if DB is stolen, attackers can't use stolen scrypt hashes to authenticate any client.

I would love to get others' feedback on this. EDIT: Found the reference: https://news.ycombinator.com/item?id=9305504

vincentdm• 10 years ago

Very interesting. Is there a reference implementation or discussion you can link to?

sinatra6• 10 years ago

I'll try to find the discussion. EDIT: Here's the discussion - https://news.ycombinator.com/item?id=9305504

sarciszewski34• 10 years ago

How are you going to calculate the scrypt hash, client-side?

Doesn't that scrypt hash then become the password, from the server-side application's perspective?

How are you storing the salt for the user if your server only knows about a SHA-256 hash.

MITM attacks won't get access to unencrypted fields.

That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scrypt calculation, a MitM can replace the code to exfiltrate the user's plaintext password. It doesn't make sense for the threat model.

sinatra6• 10 years ago

Very valid questions. Let me try to answer them and let's see if those answers are valid or not.

Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits. The server can store the salt that the client used, though.

Yes, the MITM point was minor. Just another minor security benefit on top of TLS (which takes the majority of the burden of securing against it). So, maybe I shouldn't even mention this point.

Strilanc• 10 years ago

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient.

Not sure how I feel about it.

technion2• 10 years ago

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.

dudus• 10 years ago

I learned very early on to never trust the client. An infected machine cold just not encrypt the password and now you have a database where infected clients just got sha256. That is if course easily broken with brute force or even rainbow tables.

joveian2• 10 years ago

An infected machine would more likely steal the password, then still run the scrypt. Why make it easier for someone else to steal it too?

owenmarshall4• 10 years ago

MITM attacks won't get access to unencrypted fields.

A MITM would let you hijack the JS that controls scrypt/SHA-256, so you're already at game over. You've got to deliver that to the user in some fashion (TLS!); this isn't a real win for your approach.

External brute force attackers will have to take the burden of heavy hashing.

If the attacker is trying targeted access to a site the only thing that's relevant is the time they have to expend - the hash is opaque. If they have the hash from, say, a DB theft, they're already going to have to take that burden. Your approach doesn't seem to add anything.

Storing SHA256 hash instead of scrypt hash on DB means even if DB is stolen, attackers can't use stolen scrypt hashes to authenticate any client.

I'm not sure what that means. If you steal my scrypt hash for example.net, how do you use that to authenticate me to example.net?

Your approach pushes out complexity to the clients and doesn't seem to win us anything.

nkrisc2• 10 years ago

You're putting a lot of faith in the client.

VincentEvans8• 10 years ago

Serious question: What about using a Public/Private key encryption to store the password?

- Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed.

- When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt.

- When user attempts to authenticate - the password that is provided is padded with the stored salt, encrypted with the public key and compared to the stored password.

Private key is never used when comparing passwords. Never available to the system doing authentication, etc.

The only purpose of using a reversible encryption - is to be able to switch to a different authentication provider completely transparently to the user.

I've implemented this functionality considering that we may need to switch over to active directory (or some other directory) in place of storing passwords in the database - but never used it, fearful that i would be committing some cardinal crime against proper security practices

Thoughts?

cpitman• 10 years ago

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 their password. If you are going to completely drop the password, then send each user an identifiable link where they can link their account.

VincentEvans8• 10 years ago

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 database. To transition our entire user base took a very long time (more than a year), since we had no way to compel the users to login and had to wait until they login on their own volition.

Ever since we've been reluctant to lose the ability to recover the passwords. Transition to Active Directory has been on our agenda for quite some time - and having the ability to decrypt the password for this purpose - we can make that happen in short order (AD hashes the passwords, so it will be a one-way operation of course).

But the question still stands - is asymmetric encryption strong and secure enough to take place of hashing, assuming the private key is secured? I have not been able to find any relevant sources to answer these questions.

kijin• 10 years ago

Where do you store the public key?

If you store it on the server alongside the encrypted password and salt, you're effectively using a bigger salt with a weird hashing algorithm that hasn't been vetted by any expert for the specific purpose of password storage.

If you store it on the client side, the user needs to supply the public key whenever he tries to authenticate. This has the effect of making the salt much bigger, but you don't need to use public keys to achieve the same effect. If you can trust the user to store a public key, you can trust him to store any large chunk of random bits.

So apart from the virtually useless fact that you might be able to decrypt the password with the private key (why would you even want to do that, instead of just resetting it?) your method seems to offer no real benefit compared to simply using larger salts with argon2/scrypt/bcrypt/whatever.

VincentEvans8• 10 years ago

Not sure i understand your reply at the moment, but i will definitely try.

We are using RSA. The public key is on the server. We simply using RSA as a "hashing algo". Randomly generated salt is added to the password sent by the user to make the password (much) longer as well as strengthen it before the encryption takes place.

I have explained the reasons for storing the passwords (for the time being, hopefully temporarily) in other replies in this comment branch:

quote:

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication at all - our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

To enable us to make this transition possible - for the time being we store the passwords, since as i explained in another reply, we must make this transition transparent to the users and we have legitimate users that login once a year (think credit report, just an example, not our business), so we can't intercept the credentials within a reasonable time period.

/quote

cyphar• 10 years ago

Because it would leak information about the length of the password (and would require length limitations on passwords if the encrypted password is stored in a database). More importantly, I don't see what benefit you get from encrypting your password (read: slow and causes the above issues) rather than using hashing algorithms. If you use the crypt standard for storing your hashes, you can also update the hashes on login when migrating to a new algorithm. Unix systems have solved the "storing passwords" problem. We just need to keep iterating on "what hashing algorithm is trending on HN this week".

VincentEvans8• 10 years ago

Hi, i explained our reasons in replies to other posts, i think they are if not good, at least worth considering.

quote:

/quote

The approach i used applies salt. It can also pad the password to some standard length, if desired. Though it currently doesn't do that.

Slowness of the algo is perhaps a benefit in a way? In my testing it is still fast enough for our use (we are not facebook).

Vintila• 10 years ago

I'd been considering something similar, never really made a PoC though.

How about this: User provides their public key when they signup. To authenticate, server produces a nonce and sends to the client, client signs the nonce with private key and sends the result, server verifies signature with public key.

VincentEvans8• 10 years ago

Interesting thought, i need to think about it - i will and write a reply when i have a little more time than i do at present.

What are your reasons to hold on to the password?

zaroth• 10 years ago

This only works for deterministic encryption like "textbook RSA", not for any semantically secure encryption, which would produce different ciphertext each time you run it.

I would worry about trying to dual-purpose the encryption like this. If you feel like you must have a way to get the plaintext password back, which BTW you really really do NOT want that liability, but anyway, the safer choice would be to use a semantically secure encryption of the password, and then ALSO hash the password using the current best practices. Use the hash for now to authenticate users, keep the ciphertext if you must, but you'll probably regret it.

VincentEvans8• 10 years ago

Thanks for you reply. It is indeed RSA that I used (from .NET framework).

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication at all - our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

What i try to get out of the replies - is whether there's nothing immediately broken about using asymmetric encryption that endangers us aside from the understandable but not immediate concern about liability.

P.S: Earlier i mentioned "intercepting credentials" in our code - and wanted to highlight that the ease of doing that is precisely the reason why we really want to separate ourselves from handling credentials in any form.

xs• 10 years ago

Lame title. Story talks about storing password hashes and not passwords. I'm still looking for a solution to storing actual user passwords. Scenario: All laptops in the company have a unique local administrator password. How do I manage this effectively as a domain admin?

jsmeaton2• 10 years ago

Use a password manager of some kind. Lastpass is nice, and has an enterprise component that lets you share passwords with co-workers or teams.

astockwell2• 10 years ago

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks.

There is an open issue in Coda Hale's bcrypt repo about this: https://github.com/codahale/bcrypt-ruby/pull/119

My stance on posting "best practice" articles is: you must follow all best practices in them.

sarciszewski34• 10 years ago

I believe the Ruby example is incorrect

Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison.

I've left a comment on the pull request so that, hopefully, it can be merged.

(and likely others)

Which others?

astockwell2• 10 years ago

After re-reading the others in depth, all other examples appear to use appropriate comparison methods (knowing nothing of the underlying implementations). I've updated my comment to clarify.

I see your team is actively posting on the bcrypt-ruby issue #119 as we speak, so I guess I'd say wait for the PR to merge, or manually implement the approach they've outlined to secure compare: https://github.com/codahale/bcrypt-ruby/pull/119/files

Freaky2• 10 years ago

As mentioned elsewhere in the thread, this isn't a "you must", this is a "you might as well".

Timing attacks depend on an attacker having control over the hash being compared (e.g. they have a HMAC in a cookie they're sending you, and they can adjust it character by character) - with randomised secret salts and server-side hashing, this isn't the case.

The SCrypt example is the one I'm more concerned with. The defaults there are 1MB of RAM and 64-bit salts, both of which could do with increasing. I have an open issue on this: https://github.com/pbhogan/scrypt/issues/25

As it is, the example would probably be better as this:

    password = SCrypt::Password.create(usersPassword, salt_size: 32, max_mem: 16*1024*1024)

You'll be pleased to know SCrypt::Password#== is at least constant-time.

PixelB• 10 years ago

I use an ultra secure method for my passwords, it is 100% unhackable.

Proprietary Analog Password Encryption Routines.

sarciszewski34• 10 years ago

That's not very useful for web programmers that are handling their users' passwords, is it?

damon_c• 10 years ago

I have always been impressed by the way django does it.

https://docs.djangoproject.com/en/1.9/topics/auth/passwords/

movedx• 10 years ago

Hashicorp's Vault (vaultproject.io) is also an excellent way of controlling access to secrets and back ends, such as PostgreSQL.

It's worth spending the time to learn, implement, and integrate into the security best practices you should already be deploying.

dogweather3• 10 years ago

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.

sarciszewski34• 10 years ago

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

dogweather3• 10 years ago

Heh, good point.

jsmeaton2• 10 years ago

I agree for the majority of cases. There still exist classes of applications where you can't rely on personal accounts on social sites for auth. Anything that runs behind your firewall for instance. In my particular case, we run some "enterprise software" on behalf of our customers, whose users regularly don't even have a work email address. Our customers are certainly not going to want users to use their own personal addresses.

Most of this can be solved with SAML, but it requires all of these old enterprisey stacks to convert their auth systems to be SAML compatible.

In the long term though, I think SAML and OAuth will be more prevalent than using passwords everywhere.

Are there any OAuth providers established that simply provide email addresses? I feel there's definitely room for a company to setup an OAuth provider that doesn't do anything except provide identity, rather than relying on personal information harvester companies (FB, Google, etc). The hard part would be getting onto the approved OAuth providers list of all the sites that users want access to.

CM30• 10 years ago

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.

dogweather3• 10 years ago

Not everyone uses Facebook or Google or Twitter after all

Yep, I do tailor the selection of oauth providers to my audience. E.g., an app for devs = google, github, and gitlab.

xjlin0• 10 years ago

Ruby's argon2 gem is pretty good!

cm2187• 10 years ago

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.

technion2• 10 years ago

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

sarciszewski34• 10 years ago

If you're using any of: PBKDF2, Bcrypt, Scrypt, Argon2, then you're fine. Our recommendation is:

    1. Use the best option available, but
    2. We provided example code in multiple languages for the
       best one that's widely available

oliwarner6• 10 years ago

Disappointed that the first solution isn't: Let somebody else do it.

I know this doesn't apply to banking, etc but 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me. Please pick a secure implementation of oAuth2 and let people store their credentials wherever the hell they want to.

I'm bored of getting hits from "Have I been pwned?"

sarciszewski34• 10 years ago

This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then?

99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me

Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).

oliwarner6• 10 years ago

You don't integrate with a provider. You implement the protocol and let your users supply a URL. Layering on popular alternatives (Facebook, Google, etc) help, but use the Stack Exchange model. Let users do what they want to do.

That way users can be their own oAuth providers if they want.

oliwarner6• 10 years ago

I meant OpenID. I literally couldn't see I was saying the wrong thing. Everything you say about OAuth is true. I'm an idiot. I'm sorry for getting so blue in the face.

A hybrid between the two (common OAuth-style endpoints and any OpenID endpoint) is the best solution for everybody.

firelink• 10 years ago

I kind of don't like this article. I think we should be teaching people best practice for securing and storing a password, not simply giving them a library.

How to Safely Store Your Users' Passwords in 2016

Related Stories