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

271–280 of 321 posts

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

#271

Post by melicerte »

x1798DE wrote: post #265
melicerte wrote: post #238

Earlier quoted context omitted.

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

Maybe this isn't practical for some people, but I think it's bad practice to use your work credentials for something you plan to "take with you" when you leave. Best to keep a strict separation of work and personal credentials.

Yes and no. Yes, obviously for your bank account or something that is very personal.

But as an IT manager, you could enforce people from your company to use their work email address for accounts that are directly linked to your company activity. For instance, We use a online tracker[1] for Use cases management. When someone leave the company, it does not have access to its email account. Consequently, he/she would no longer have access to our tracker by not having access to its email address. This could rather convenient scheme.

[1] Pivotal tracker (who requires password to connect).

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

#272

Post by VincentEvans »

zaroth wrote: post #252
VincentEvans wrote: post #150

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…

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

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.

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.

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.

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

#273

Post by melicerte »

threefour wrote: post #269
melicerte wrote: post #238

Earlier quoted context omitted.

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

I asked Medium about this. They replied, "if you don't have your Twitter/Facebook account connected to your Medium account, you won't be able to sign in at all. You'll need to contact us to regain access to your account. If you don't want this to happen, please do not use an email address you think you won't be using in the future."

I can't figure what is the Medium process when they are being contacted to regain access to an account.

In a near future, we could have a "Argh I lost my email address" link replacing the now very common "I lost my password". Nevertheless, I have no clue what would be a standard process to recover a lost account because of a lost email address, maybe a SMS based process and personal questions like "what was your first pet name?"

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

#274

Post by VincentEvans »

mkj wrote: post #200
VincentEvans wrote: post #156

Earlier quoted context omitted.

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.

There's a couple of us here watching the replies to this - as this has been our concern for a while and this is a great opportunity for us to get some feedback. Thank you for your reply.

Interesting point about it being an advantage. I am actually going to make a note of this.

One way of handling the private key that i proposed - was to use a privileged access vault like Thycotic. Or just have it on a USB key in a lockbox.

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

#275

Post by VincentEvans »

cyphar wrote: post #176
VincentEvans wrote: post #150

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…

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

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

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

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

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

#276

Post by VincentEvans »

Vintila wrote: post #220
VincentEvans wrote: post #150

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…

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.

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?

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

#277

Post by VincentEvans »

kijin wrote: post #168
VincentEvans wrote: post #150

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…

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

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

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

#278

Post by novaleaf »

dsp1234 wrote: post #266
novaleaf wrote: post #253

Earlier quoted context omitted.

when I was figuring out password security I did some tests. on my phone (a galaxy s3) I got about a 40x slowdown of pbkdf2 versus an x86 server running a compiled version (C I assume). I suppose running the js version on a server might give a better runtime, but I'd think the point of a js KDF is to run on the client, not the server. edit: and I'd assume a GPU version would be faster.....

but I'd think the point of a js KDF is to run on the client, not the server. bcrypt is used on the server (node.js) to hash a user's password before storing it in the database. Then later, when a login is done, the password from the login is checked against the stored hash to see if the match (and by implication, that the original passwords are the same). So the usage is mostly on the server as expecting a client suc…

right, but running bcrypt on a server, why run a pure javascript version? Why not the C-compiled version?

So to me the logic behind a pure js version is one that can run on the client too. It actually sounds interesting, as it could improve password security! But it's just too slow.

In my case, I ended up sha512'ing the password client-side, and use that as the "password" sent to the server. If there were a native KDF for all browser's i'd use that instead.

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

#279

Post by minitech »

novaleaf wrote: post #253
minitech wrote: post #219

Earlier quoted context omitted.

I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well as far as password storage goes, so a pure JavaScript bcrypt is bad mostly because it’s blocking on Node and not because it’s too slow to be useful. Please don’t pull numbers out of nowhere.

when I was figuring out password security I did some tests. on my phone (a galaxy s3) I got about a 40x slowdown of pbkdf2 versus an x86 server running a compiled version (C I assume). I suppose running the js version on a server might give a better runtime, but I'd think the point of a js KDF is to run on the client, not the server. edit: and I'd assume a GPU version would be faster.....

The speeds you were seeing might have had less to do with the fact that it was JS and were more about the mobile device being much slower than the server, then. This isn’t really avoidable, but a 40x slowdown isn’t the end of the world for bcrypt.

Important to note that the only advantage of hashing or prehashing passwords on the client is offloading work from the server. It doesn’t improve security (on a website).

Re: GPUs:

- One of bcrypt’s advantages is that its memory requirements make using a GPU provide much smaller returns compared to, say, iterated MD5: you can’t parallelize it as much.

- The point of using GPUs to generate password hashes is generally only to break them, because GPUs can do lots of hashes in parallel. Your web service probably doesn’t need to generate that many hashes at the same time, and it probably isn’t otherwise running on a server with a computey GPU. Clients’ GPUs? Even less parallel, they’d generate on the order of one hash per year.

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

#280

Post by darkstar999 »

tokenizerrr wrote: post #237
darkstar999 wrote: post #157

Earlier quoted context omitted.

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.

Hashing is considered one-way encryption, no?
Post reply on HN