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

71–80 of 321 posts

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

#71

Post by sarciszewski »

balls187 wrote: post #65
rehevkor5 wrote: post #54

Earlier quoted context omitted.

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

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…

> What is more valuable to an attacker?

Generally: Being able to deploy malware through a site users trust so you can attack them directly, en masse.

But the password hashes are a good runner-up.

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

#72

Post by rms_returns »

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

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

#73

Post by corobo »

jcrawfordor wrote: post #61
jobigoud wrote: post #53

Earlier quoted context omitted.

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

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…

I may be confused but how do you validate the password using the token if you've lost it?

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

#74

Post by jtwebman »

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.

  });
});

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

#75

Post by [deleted] »

Someone1234 wrote: post #70
sarciszewski wrote: post #56

Earlier quoted context omitted.

> I literally don't understand what it is you're getting at. I truly hope this will help then: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass... "Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you. > Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in…

> 3DES is a block cipher. MD5 is a crytographic hash. 3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar. > Neither of them are password hashes. 25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years. But no doubt you'd playi…

[deleted]

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

#77

Post by herbst »

rms_returns wrote: post #72
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 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 :/

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

#78

Post by dsp1234 »

jtwebman wrote: post #74

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, functio…

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

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

#79

Post by herbst »

lukev wrote: post #11
rcconf wrote: post #9

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

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

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.
Post reply on HN