201–210 of 219 posts
Earlier quoted context omitted.
Wrong. Collisions can be found in MD5 in 2^21 time due to an attack by Xie and Feng. 2^64 is a very respectable number and is not practical for people to do on their home machines. 2^21 is.
Plus you only need a collision to break into a system that uses hashed passwords, not a preimage.
Earlier quoted context omitted.
Plus you only need a collision to break into a system that uses hashed passwords, not a preimage.
Clarify? Collision attacks by definition do not feature an existing digest as input so they are not useful for breaking into a system secured with a digest.
My issue is asking a lot of people to change their password because I've decided to change my encryption algorithm. Is there a best practice for upgrading encryption without forcing users to do that? Something like when the user logs in, hold onto their plaintext password for a bit, confirm it's correct against your current algorithm, and then re-encrypt it with bcrypt?
Why not do it behind the scenes? Simply use the existing MD5/SHA1 hash as input to bcrypt and update all password hashes in your database in one go. Then, whenever the user logs in you first apply the old hash function followed by bcrypt before comparing with what you have in the DB.
My issue is asking a lot of people to change their password because I've decided to change my encryption algorithm. Is there a best practice for upgrading encryption without forcing users to do that? Something like when the user logs in, hold onto their plaintext password for a bit, confirm it's correct against your current algorithm, and then re-encrypt it with bcrypt?
Good question. My gut instinct would be to do just that but I wonder if there's a better way. You'd probably also want to track the encryption of each user so you know when you can make the final switch. Another alternative is to just send "update your password" emails to everyone framing it as an improvement to your site's security.
I guarantee everyone with a decent spamfilter will miss those e-mails - that looks exactly like a standard phishing attempt.
Micrsoft Active Directory stores what it calls an NT Hash in NTDS.DIT files on domain controllers. These are unsalted, md4 hashed, unicode strings. They are fast and easy to crack if you ever do get your hands on them. The point is that many big companies don't do passwords right, so why expect Gawker to do so? Edit: md4 is not a typo. They use md4 not md5... OK.
Earlier quoted context omitted.
I'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)
A machine with a few GPUs can compute hundreds of millions of SHA1 hashes per second. http://www.win.tue.nl/cccc/sha-1-challenge.html
Earlier quoted context omitted.
Plus you only need a collision to break into a system that uses hashed passwords, not a preimage.
Clarify? Collision attacks by definition do not feature an existing digest as input so they are not useful for breaking into a system secured with a digest.
Please disregard my comment above.
This key could be generated in real time and would not be displayed anywhere on the form and will be transferred in stealth mode to the server.
With no passwords to enter or transmit, there will be nothing to hack.... If the key generated in origin is itself a strong key decrypting information stored on the server will require first hacking the key which if not stored on the server in the first place will make life hell for hackers as they will require access to the individual devices as well.
Cheers, gurudatt
Earlier quoted context omitted.
That's true of passwords over a certain strength, for sure. And it always has been; "6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. But as computing power increases, that minimum strength is being pushed out. bcrypt lets us hold the line by keeping pace with computing power— couldn't it also give us the ability to push back? How many users are using the…
> As it stands today, anyone using one of those is instantly compromised the moment the hash file is accessed. How? If hashing one password takes one second, and you have a dump of a thousand users, it will take you a million seconds to try just 1,000 common passwords on that list. Are you thinking of unsalted hashes, perhaps?
Earlier quoted context omitted.
That's true of passwords over a certain strength, for sure. And it always has been; "6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. But as computing power increases, that minimum strength is being pushed out. bcrypt lets us hold the line by keeping pace with computing power— couldn't it also give us the ability to push back? How many users are using the…
I think it would be enough to get hold of the 1,000,000 most common passwords and tell the user it's not allowed.