131–140 of 199 posts
edit That number is actually active users and I do apologize the number of registered accounts is estimated to be over 645 million! edit2 Actually 4.9% of the estimated accounts were "leaked" (if this is an actual twitter leak since still no official word)
Earlier quoted context omitted.
Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU. Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which…
Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition. https://github.com/P-H-C/phc-winner-argon2
Can someone change the op's link to: https://www.leakedsource.com/blog/twitter The real source, not this redundant media crap that buried the lede...
> Subscribe today to view the raw data itself and receive unlimited searches! As low as $0.76 a day! Is that site legit ?
Earlier quoted context omitted.
You can hash a fixed salt + password + some other user info like surname or email address. That way if you have the salt you can't just compute the hash of salt+"123456" to see who had that, you have to compute separately for each user.
What? No. Don't use a fixed salt. Each record should have a unique, random salt. You then store salt:hash(salt+password). There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
The owasp link you provided explains the two goals of using a salt:
1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem.
2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password.
Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
Twitter used to support authentication to their API's with a username / password combination. So this leak could come from an app or service that utilized Twitter apis in some fashion and was hacked.
Earlier quoted context omitted.
You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.
> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."
Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.
Twitter also does 2-Factor Auth. If you value your Twitter account, in addition to changing your password (which hopefully is unique amongst your accounts), also activate 2FA.
Was just trying to set this up, and not great (IMHO). The feature is called "Login Verification", I think, and it's only SMS based, no Google Authenticator / Authy style one-time password... Also, it was saying I needed to verify my email address before that feature can be used, but there was no option to verify the email address that is used since I've registered almost a decade ago... Had to change my email (used t…
Earlier quoted context omitted.
With bcrypt you can set a parameter which determines how slow it is. So if hardware gets faster, you can change the parameter. (brcrypt uses 2^n iterations where n is the parameter.) So it doesn't matter on what hardware, if you want bcrypt to take 1 second on modern hardware (for any value of "modern"), you can.
Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.
Make it 15ms for an attacker and it becomes an hour per account just for the dictionary.
Earlier quoted context omitted.
What? No. Don't use a fixed salt. Each record should have a unique, random salt. You then store salt:hash(salt+password). There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible. The owasp link you provided explains the two goals of using a salt: 1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "pa…
(I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)