291–300 of 526 posts
Dear All - Your passwords should be considered compromised. Hashing is merely a deterrent, it does not prevent cracking.
6500 bcrypt(5) hashes/second with custom FPGA: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=703252...
But dictionary and password list-based attacks are expected to be quite effective anyways.
http://www.openwall.com/presentations/Passwords13-Energy-Eff...
to passively authenticate the user base. Applications such as Slack and Yammer have corporate info that competitors or corporate espionage people would want.
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.
Of course, even if they can't steal everyone's passwords, maybe the hackers will try to crack the passwords of higher profile targets.
Earlier quoted context omitted.
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
Why combine hashes? Just use XOR. If bcrypt can protect "not_my_password", it can certainly protect "KKQ{H]zTDWVSJVA", which is the former XOR'd by "%$". XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt; XOR is fast enough to evade any sort of timing attacks, too.
Earlier quoted context omitted.
Major privacy issues, single point of failure etc etc. We leave payments to third party services because nobody wants to deal with the compliance nightmare that PCI-DSS is, not for security reasons. Payment is also mostly less sensitive to availability and latency issues than authentication.
So in a world where PCI-DSS isn't a thing, you're fine entering your credit card data directly on the forms available on random websites? Why's a password so different, seeing as most people reuse those passwords? Why do we essentially allow (and yes, I am excluding those that use password managers in this statement, I'm one of those) access to our webmail and other critical services to random websites on the interne…
Yes. It might be a hassle should someone misuse it, but the status-quo effectively means if I didn't make the purchase I'm not responsible for it.
More importantly, this was proven before PCI-DSS was a thing.
How does one discover that they were hacked? The post states that the breach occurred during February, and this is the end of March... did it just take them a long time to react and write a post about it, or did they likely discover after the fact? If so, how?
Earlier quoted context omitted.
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, r…
The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's the risk that you screw up in implementing the pepper?"
Earlier quoted context omitted.
Because the set of values that make sense as linear round counts doesn't overlap with the set that makes sense as log base two work factors. Every implementation takes the log number; it's the only number people ever discuss.
And do they call it "rounds"? I've only heard it called work factor.
Earlier quoted context omitted.
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, r…
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…
Otherwise such advices should be ignored.