221–230 of 526 posts
Earlier quoted context omitted.
10 rounds of bcrypt is "dire"?
Yes? 16 rounds take 1ms on my (old) machine. In Python, no less.
Earlier quoted context omitted.
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
That sounds like fuzzy scare-mongering to me. 1) You should not invent your own algorithm. That's a given. That's why you use bcrypt/scrypt. 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case). 3) There's nothing wrong with nesting algorithms (just remember to use hex/base64 encodings, not binary). For example Facebook passes passwords through half a dozen algorithms. They call it…
Earlier quoted context omitted.
Lots of options. * You can buy a hardware token. https://www.duosecurity.com/product/methods/hardware-tokens * You can have Duo call/text you every time you want to log in. * You can use some other device you have that runs a mobile OS. I had Duo set up on my wifi-only iPad while I was using a feature phone for a few months a year ago. (I eventually gave up on that and got a smartphone, though.) * You can buy a used/…
I have a Nokia 1020 Windows Phone. There is a Duo app for it, but it's single account. Duo hasn't updated their WP app since 2012.
Earlier quoted context omitted.
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.
Please do not ever consider "rolling your own crypto" a walk in the park. Unless you have a serious security background and some actual cryptography education and research never, never, NEVER do this. It is not negligible, and it is not safe.
Earlier quoted context omitted.
It's heartening to me. I've seen small practices with atrocious IT security. No WAY is self-hosted (for the thousands of small practices with maybe a couple of clueless help-desk types) even a billionth as secure as a professionally secured cloud service. Also, "cloud" for services like this means "your own private instance of the software running in a private VM in our datacenter" not "your own customer_id in a shar…
If you're small, cloud may be better, but if you're large it often isn't.
I guess what I'm saying is that regardless of who you are, there is no easily discernible best practice playbook, just a sea of tradeoffs generally made by people with a woefully inadequate grasp of the risks involved. Heck, even the best security people are at a disadvantage in the asymmetrical battle of infosec.
I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
Earlier quoted context omitted.
Yes? 16 rounds take 1ms on my (old) machine. In Python, no less.
I hate to suggest that your observation is wrong, but 16 rounds should take orders of magnitude more time than 1ms. 16 rounds using Mindrot's Java implementation of BCrypt on my admittedly old 2009-vintage i7 consumes 6.3 seconds to hash a 10-character password.
Earlier quoted context omitted.
While technically true, this seems like it would be computationally infeasible, or at least impractical, given that they were not just hashing but also salting the passwords. Of course, I barely know anything about computer security, but at least it should prevent attacks using rainbow tables I think?
No, a simple password like "slack123" should be easy to crack with any usable password storage method.
Out of interest, where where the per-user salts stored I wonder? Where would people normally store this if not next to the hashed password in the same table?
Yeah it's Usually the same table, but salt is used to prevent hackers using already generated hash map of popular passwords to diff with your password hash directly without computing.
Earlier quoted context omitted.
I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…
passwordHash = bcrypt(salt + password) encryptedHash = encrypt(passwordHash, pepper) This way you can rotate your pepper by doing: decryptedHash = decrypt(encryptedHash , oldpepper) encryptedHash = encrypt(decryptedHash , newpepper)