101–110 of 321 posts
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.
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…
Name and shame.
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.
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.
Earlier quoted context omitted.
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.
The main limitation of that is that your passwords are limited to what you can memorize. Which, for most people, is not very much. Even for just one password, never mind for multiple services. I think if you're a pragmatic security conscious person you'd weigh the trade offs...and I thinking of it as just "simply memorize it" opens you up to other problems.
People used to memorize whole books.
Or, we could move to not storing passwords at all, viz client certs and SRP.
SRP still stores crackable password verifiers, and is tricky to implement safely.
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.
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] - ht…
Earlier quoted context omitted.
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] - ht…
BUT NODE.JS IS NON BLOCKING?!?@?!?!?! Kidding.
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.
Earlier quoted context omitted.
Name and shame.
[deleted]
[1] If so, tell them about this in a way that will get their attention without causing their customers or them any harm.