"passwords hashed with MD5" Jesus seriously?
Yahoo discloses hack of 1B accounts
501–510 of 596 posts
Re: Yahoo discloses hack of 1B accounts
#502Earlier quoted context omitted.
Just leave it at passwordpassword, it will be leaked eventually anyway Strong passwords that need to be memorized shouldn't be wasted on security bozos
He doesn't need to memorize it. He mentioned he used 1Password to generate it. I'd assume he's storing it there too.
I've always wondered when 1Password is going to get hacked..
Re: Yahoo discloses hack of 1B accounts
#503Earlier quoted context omitted.
honest question: if you're going to the extent of already using a password manager, why isn't every site getting a unique password?
honest answer: one of those sites is your recovery email, the one way back into your digital life if something goes deeply wrong. It's the password reset email if another site is hacked. It's the "bootstrap myself from some other computer" account if your machine dies or your house burns down. IMHO you should memorize one very strong password for one somewhat-trustworthy site.
> IMHO you should memorize one very strong password for one somewhat-trustworthy site.
This would be necessary if one is using a password manager, which is something everyone should use for multiple reasons and benefits.
As an alternative, you could also invent a scheme for passwords. Have a prefix, body and suffix for every password. You decide which ones should be static and which ones should be something that's easy to derive just by looking at the website name (part of the name, few letters from specific positions). You can also have different static pieces based on the nature of the site - email vs. bank vs. online store. This may not be as good as using a unique password per site that's a random strong password generated by a password manager, but is easy to remember depending on how you construct it.
Re: Yahoo discloses hack of 1B accounts
#504Earlier quoted context omitted.
Why do you assume the password would be leaked eventually? Usually hashes are leaked (as in this case), not passwords.
leaking unsalted md5 passwords == leaking passwords
MD5 is terrible for human passwords because it's fast. But md5 is not actually broken for password storage purposes. If you use a long random password, md5 is enough.
Re: Yahoo discloses hack of 1B accounts
#505This is a time where a decent password manager comes in handy. I can look in my password history to see what my password was in August 2013, and see if that password is still in use anywhere else, then change the password on those sites.
I hate having a secondary system just to get access to my accounts. I use a password algorithm. This ensures I have a unique, easy to remember (or derive), hard to guess password for every account: http://penguindreams.org/blog/my-accounts-been-hacked-no-it-...
It seems like you're getting downvoted (not sure why). I use "password algorithms" like you've blogged about (but very different in nature) to have memorable passwords for some sites. For many other sites in the last several years, I have started moving to creating unique passwords and using a password manager to store and use them.
Re: Yahoo discloses hack of 1B accounts
#506Earlier quoted context omitted.
Not if it's my password. I use ~100 bits of entropy.
Could the attacker find an easier to find string that matches the same md5 hash?
The current best attack wrt matching an existing hash brings MD5's 128 bits of security down to 123. So no, that's not going to happen.
Re: Yahoo discloses hack of 1B accounts
#507Earlier quoted context omitted.
Care to explain? The hashes are what is compared so it seems it's important.
The existence of crafted collisions -- being able to create a pair of M1 and M2 such that MD5(M1) = MD5(M2) -- is primarily relevant to situations where MD5 is being used as a signature algorithm, such as in certificate issuance. In these applications, being able to generate a pair of documents with the same hash is catastrophic. Being able to generate a pair of passwords that are treated as equal, on the other hand,…
Google(MD5(M1)) = MD5(M2) is more than enough for most users.
Re: Yahoo discloses hack of 1B accounts
#508> August 2013 > hashed passwords (using MD5) I don't even know what to say. > investigating the creation of forged cookies that could allow an intruder to access users' accounts without a password. Based on the ongoing investigation, we believe an unauthorized third party accessed our proprietary code to learn how to forge cookies How is this possible? Aren't most auth cookies just a session ID that can be used to lo…
1) As Yahoo "upgraded" all password storage in UDB (where all login / registration details are stored) to be bcrypt before 2013, I'm curious how this was possible. 2) Yahoo doesn't use a centralized session storage. If you know a few values (not disclosing the exact ones) from the UDB, it's theoretically (guess not so theoretical now) possible to create forged cookies if you steal the signing keys. To my knowledge, t…
It seems that Yahoo has a problem with moribund accounts- many people had a Yahoo ID 10-20 years ago, and then abandoned it.
If these accounts are not deleted (and there are a bunch of organisational reasons not to), then the MD5 hash has to be kept around somewhere, until the user re-enters a password and a better hash is generated.
Re: Yahoo discloses hack of 1B accounts
#509Earlier quoted context omitted.
My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Allow some or all tokens to "refresh" by calling a particular endpoint (call with valid token and get a token with expiry from now). Optionally add some form of identifier to the token (user_id works great) so that you can push a message…
> Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Doesn't JWT already have this - "exp" is a reserved claim for expiration time? https://tools.ietf.org/html/rfc7519#section-4.1.4 4.1.4. "exp" (Expiration Time) Claim The "exp" (expiration time) claim identifies the expiration time on or after which the JWT…
Yes but that is more for standard idle time expiration.. The problem being addressed above is for actively invalidating an existing JWT for a user once they already have it (and before the default/original expiry is met).
Re: Yahoo discloses hack of 1B accounts
#510Earlier quoted context omitted.
It sort of does matter for bcrypt, surprisingly: http://security.stackexchange.com/questions/39849/does-bcryp... In the interests of hewing closest to cryptographic reality, I design not to allow a password longer than the algorithm can usefully use.
That's just a bug. Truncation invalidates the 'stored properly' part of the statement.
Could you expand on that? I did not think bcrypt was responsible for storing the resultant hash. The limit appears to be in calculating the hash.