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
261–270 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#262I 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…
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.
Re: How to Safely Store Your Users' Passwords in 2016
#263Earlier quoted context omitted.
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.
LOL, check their Facebook pictures and see if they are playing an instrument in any of them. Most people don't play more than 1 instrument, so it's probably their first.
It's not even that tough. Just guess "piano" and you'll be right 40% of the time. If you get a second guess try "violin".
Re: How to Safely Store Your Users' Passwords in 2016
#264Earlier quoted context omitted.
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.
My question was: "What if your users don't trust any of the existing providers on Earth?" It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust. Offer OAuth2 as an alternative to passwords: Great move. Only offer OAuth2 and don't let people create an account: Questionable.
I did answer.
They can host their own.
I don't understand why they would trust over a dedicated authentication storage place but that's their choice. And yes, there is also every possibility to offer direct credentials, per the Stack Exchange model (they host their own oAuth server and allow simple registrations).
Re: How to Safely Store Your Users' Passwords in 2016
#265Earlier quoted context omitted.
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...
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.
Re: How to Safely Store Your Users' Passwords in 2016
#266Earlier 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.....
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 such as a mobile device to do large rounds of CPU intensive work just to login isn't going to make for happy customers.
Re: How to Safely Store Your Users' Passwords in 2016
#267Earlier quoted context omitted.
I think he's going for SHA256(scrypt(password, salt, work_factor)) and saying the bare SHA256 is sufficient. As opposed to SHA256(salt+scrypt(password, salt, work_factor)). I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.
> scrypt(password,salt,work_factor) on the server is plenty hard to attack For a large enough work_factor. In practice "large enough" is usually interpreted to mean "something that seems safe without being so large that I need to buy lots more servers" The argument (which I'm interested in, but not yet sold on) is that moving the scrypt to the client allows you to pump up the work_factor even higher than you would ha…
After thinking about it more the concept is interesting, but the main fear I have is that doing it in a web browser with JS is next to impossible to secure. Maybe if vendors got on board...
In general though, pushing auth down to clients in Javascript makes my skin crawl. You're one XSS away from having an attacker no-op your scrypt and return SHA256("secret-attacker-password") on registration. The logical follow-up to that: 'have the server run scrypt the first time' -- but then you've just moved the tough work to user registration, which seems just as exploitable.
I dunno. Safe crypto is hard enough already; I'm not sure pushing it into Javascript on the browser makes it any easier.
Re: How to Safely Store Your Users' Passwords in 2016
#268Earlier quoted context omitted.
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.
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 )
"explain why you forgot your password"
Re: How to Safely Store Your Users' Passwords in 2016
#269Earlier quoted context omitted.
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...
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."
Re: How to Safely Store Your Users' Passwords in 2016
#270Earlier quoted context omitted.
My question was: "What if your users don't trust any of the existing providers on Earth?" It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust. Offer OAuth2 as an alternative to passwords: Great move. Only offer OAuth2 and don't let people create an account: Questionable.
I did answer. They can host their own. I don't understand why they would trust over a dedicated authentication storage place but that's their choice. And yes, there is also every possibility to offer direct credentials, per the Stack Exchange model (they host their own oAuth server and allow simple registrations).
> I don't understand why they would trust over a dedicated authentication storage place but that's their choice.
What if happens to be a security engineer, and happens to be Silk Road 13?
The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.