201–210 of 526 posts
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.
The real downside is that there's a better, proven way to do the same effective thing, which is make a database-only compromise require additional work, without rolling your own crypto. It also supports doing things retroactively for real (not some of the hacks being discussed in this thread) and key-rotation. All the upsides, with none of the downsides.
Earlier quoted context omitted.
The default cost for most libraries and languages is between 10 and 12, which is considered too low for 2015 but still pretty good. As long as they're at the default or above it, I wouldn't be too concerned about an attack against the whole DB. Targeted cracking attempts against specific hashes are definitely still an issue though.
If I set bcrypt cost to 11, hashing takes 0.1 seconds . At 12, it takes 1 second roughly. Setting it to anything higher leaves my service open to Denial-of-Service attacks, so I'm very hesitant to increase the cost factor. To you have a credible source for the "10..12 is too low for 2015" claim? HHVM 3.6 on a small Ubuntu server
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(11))", setup="import bcrypt", number=5) / 5
0.13497538566589357
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(12))", setup="import bcrypt", number=5) / 5
0.28287739753723146
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(13))", setup="import bcrypt", number=5) / 5
0.5341608047485351
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(14))", setup="import bcrypt", number=5) / 5
1.069920015335083
>>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(15))", setup="import bcrypt", number=5) / 5
2.151028203964233
That's five repetitions of a bcrypt hash with the work factor passed in bcrypt.gensalt(). The resulting units are seconds.
Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.
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.
Can we go back to IRC now, please! Slack is not only distracting, proprietary, but it is also pretty expensive. Let the mere mortals use it, but we should stay away!
I don't think IRC quite offers the feature set that Slack users would be expecting, does it?
Why do I have to install Google Authenticator some sort of other app for 2factor here? Why can't you send me a text like everyone else does? EDIT: Slack responded that they do not support SMS yet .
Because you can't trust SMS-based two-factor authentication. http://en.wikipedia.org/wiki/Multi-factor_authentication#SMS... http://webcache.googleusercontent.com/search?q=cache:UiwfUal...
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…
In incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme: bcrypt(bcrypt(password, salt), pepper) And do a pass on all your database entries like bcrypt(old_hash, pepper)
bcrypt(password, salt+pepper)
bcrypt(bcrypt(password, salt), pepper)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...
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 the "onion". And it includes a pepper.
4) As for being effective, I think the SQL injection case speaks for itself.
5) As for rotation - just don't do it. You pepper gets compromised? Who cares, add a new one on top of the old one.
Also, I'm confused at how the proposed alternative would be harder to get wrong:
> Encrypt The Output Hash Prior To Storage