551–560 of 596 posts
I can imagine something like re-hashing the existing one with a better algorithm and some salt, and storing new ones solely using the new algorithm + salt. But that introduces some additional complexity because every hash needs information about how it was hashed (MD5 + X vs. just X).
Is there an established best practice for this?
Earlier quoted context omitted.
Yep, people who've run marginally popular sites have dealt with this before. Give someone a text box and watch them try to stuff 4GB of content in it. There has to be a cutoff somewhere, but as you note, it should be well outside of the realm of reasonable password lengths (hundreds of characters).
GitHub is the only website I can think of off the top of my head that doesn't limit to an arbitrarily small number (aka <100). Do you name any other "major" websites that allow 100 character passwords?
https://github.com/plataformatec/devise/blob/88724e10adaf9ff...
Earlier quoted context omitted.
He came recommended by someone who had used him before. His country of residence was not relevant to our hiring decision.
I wish I could upvote this thread 100x. Everyone should have to deal with global competition and everyone competitive should have commiserate compensation. Unfortunately there are barriers to that (informational and transactional). I also think everyone uncompetitive should get basic income.
e.g. if a competent, competitive person receives X per year, should basic income be 0.1X, 0.25X, 0.90X, etc?
Also, would competent people working remotely from a different country be taxed to contribute to the basic income fund?
Earlier quoted context omitted.
bcrypt(md5(password)) allow the existing password hash to be reused.
No. They've stolen the hash, so if they crack it, you've just let them waltz back in. The correct response is force a password reset, and _delete_ weak hashes so that they cannot be stolen in a subsequent breach. At worst, store a bcrypted md5 password as you suggest, but only as a check for a password the user must not be allowed to use again; it _cannot_ be used to sign them in. One of the attacks you're preventing…
We're currently working on PCI compliance. In pen testing, we got dinged for not preventing re-use of prior passwords, and that bothers me for exactly this reason (plus the new NIST standards say NOT to force periodic changing).
I believe that our hashes are strong (using scrypt, salt, etc.). But the belief that you're getting it right shouldn't let you be lax in other areas, hence security in depth.
So I really object to the requirement that we keep around those old hashes.
> 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…
To prove me wrong you can try and reverse this one (unsalted , just one round):
27c8ac15df9357d92385f59aea2049e0
Security question : mothers maiden name?answer: 1q&#*v83%?ghd53 Date of birth : 01/01/2011
Using a random answer doesn't help against an attack it the security questions are stored in plain text. I'm not saying storing security questions as a hash is any better practice since these questions just need to go away. I am saying that most likely they aren't stored as hashes so a phone operator can query you hence random is only as good as something like BarkBarkRuffRuff for a maiden name.
> 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…
MD5 is still not too bad, if properly salted. And if you use multiple rounds of hashing, it can be as slow as Bcrypt. As far as I know, MD5 is still not generally broken, we only found some weaknesses. To prove me wrong you can try and reverse this one (unsalted , just one round): 27c8ac15df9357d92385f59aea2049e0
Earlier quoted context omitted.
On a number of engagements I've come across password databases that have been migrated to bcrypt. In one case I checked CVS to see who made the code change, and found the MD5 passwords on his dev box. In another I tracked down a MySQL slave that had broken replication for over a year. In both cases I tried to track down backups, but discovered neither company was keeping them. That is another possible vector.
1) I'd be flabbergasted beyond belief if there was ever a Yahoo! engineer who had user passwords on their laptop / Dev box. The technical hurdle for that would be a stretch, let alone the fact of the other ramifications of doing this. 2) there's no SQL database involved with Yahoo!'s storage of passwords. It's a custom built db system with proprietary access and replication protocols.
The NSA's MUSCULAR program for example decoded proprietary secret squirrel cross datacenter replication protocols designed by both Google and Yahoo, so that isn't much of a safe guard against state level actors.
Earlier quoted context omitted.
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.
Yes, if you add a (long - at least 32 bit) salt and something like at least 10^9 rounds of MD5 then, yeah, it's probably ok
Earlier quoted context omitted.
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.