3 ms·

For the non-experts among us, does this imply that having the bcrypted passwords in hand is almost worthless from an attackers point of view? Would it be feasib

by s_kilk 13y ago

For the non-experts among us, does this imply that having the bcrypted passwords in hand is almost worthless from an attackers point of view? Would it be feasible at all to derive the plain-text passwords from that encrypted data?

nwh 13y ago
Much harder, not impossible.
meowface 13y ago
No, the hashed passwords are certainly not "almost worthless." It does depend on the cost setting as well (you can configure how fast bcrypt takes to compute via this setting). Anyone using the password "password" or "password123" or other basic common passwords, plus passwords that are just dictionary words, will likely be cracked if the attackers make a dedicated effort no matter what setting is in use. In general though, cracking bcrypt hashes is much, much, much slower than cracking MD5 or SHA1 hashes. So anyone using a somewhat decent password is likely safe from having it cracked. While with MD5 or SHA1, you generally need a fairly entropic password over at least 10 characters in length to remain safe (a password of totally random 10 characters still wouldn't be cracked with MD5 or SHA1, but it's rare that people use /dev/urandom output as a password).
mLewisLogic 13y ago
With sane defaults, bcrypted passwords are "worthless" in the hands of a casual attacker. Somebody would have to REALLY want to access your account and have SIGNIFICANT financial/computational resources to crack it. And that only gives them one password. Significant and independent work is required for each individual password. On the other hand, there's nothing stopping a developer from doing something really dumb like setting bcrypt iterations to 1.
- s_kilk 13y ago
  >> On the other hand, there's nothing stopping a developer from doing something really dumb like setting bcrypt iterations to 1. I _really_ hope that doesn't turn out to be the case here.

by s_kilk 13y ago

nwh 13y ago

Much harder, not impossible.

meowface 13y ago

No, the hashed passwords are certainly not "almost worthless." It does depend on the cost setting as well (you can configure how fast bcrypt takes to compute via this setting). Anyone using the password "password" or "password123" or other basic common passwords, plus passwords that are just dictionary words, will likely be cracked if the attackers make a dedicated effort no matter what setting is in use. In general though, cracking bcrypt hashes is much, much, much slower than cracking MD5 or SHA1 hashes. So anyone using a somewhat decent password is likely safe from having it cracked. While with MD5 or SHA1, you generally need a fairly entropic password over at least 10 characters in length to remain safe (a password of totally random 10 characters still wouldn't be cracked with MD5 or SHA1, but it's rare that people use /dev/urandom output as a password).

mLewisLogic 13y ago

With sane defaults, bcrypted passwords are "worthless" in the hands of a casual attacker. Somebody would have to REALLY want to access your account and have SIGNIFICANT financial/computational resources to crack it. And that only gives them one password. Significant and independent work is required for each individual password. On the other hand, there's nothing stopping a developer from doing something really dumb like setting bcrypt iterations to 1.

s_kilk 13y ago
>> On the other hand, there's nothing stopping a developer from doing something really dumb like setting bcrypt iterations to 1. I _really_ hope that doesn't turn out to be the case here.