Stories
Slash Boxes
Comments

SoylentNews is people

Researchers Reverse 320 Million Hashed Passwords

posted by Fnord666 on Tuesday September 05 2017, @09:39PM   Printer-friendly
from the have-you-checked-your-passwords-lately? dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

CynoSure Prime, a "password research collective", has reversed the hashes of nearly 320 million hashed passwords provided by security researcher Troy Hunt through the Pwned Passwords searchable online database.

Their effort, pulled off with the help of two other researchers, revealed many things:

  • Interesting statistics regarding these real world passwords exposed in data breaches,
  • The fact that this database also contains some 2.5 million email addresses and 230,000 email/password combinations (Hunt intends to purge that data from the database), and
  • Some bugs in the Hashcat password recovery tool.

"The longest password we found was 400 characters, while the shortest was only 3 characters long. About 0.06% of passwords were 50 characters or longer with 96.67% of passwords being 16 characters or less," the collective shared.

"Roughly 87.3% of passwords fall into the character set of LowerNum 47.5%, LowerCase 24.75%, Num 8.15%, and MixedNum 6.89% respectively. In addition we saw UTF-8 encoded passwords along with passes containing control characters."

Source: https://www.helpnetsecurity.com/2017/09/05/researchers-reverse-320-million-hashed-passwords/

Original Submission

 
This discussion has been archived. No new comments can be posted.
Researchers Reverse 320 Million Hashed Passwords | Log In/Create an Account | Top | 31 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 4, Insightful) by FatPhil on Wednesday September 06 2017, @02:33AM (2 children)

    by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Wednesday September 06 2017, @02:33AM (#564016) Homepage
    salt destroys rainbow tables. it's very cheap to add more salt (linear growth in storage), but devastatingly expensive on the tables (geometric growth).
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   4  

  • (Score: 2) by Pino P on Wednesday September 06 2017, @04:40PM (1 child)

    by Pino P (4721) on Wednesday September 06 2017, @04:40PM (#564196) Journal

    Is it a bad idea to derive the salt from the user ID, user name, and timestamp of account creation? Or must the salt always be derived from a cryptographically random source whenever the password changes?

    • (Score: 2) by FatPhil on Wednesday September 06 2017, @07:18PM

      by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Wednesday September 06 2017, @07:18PM (#564229) Homepage
      Salt effectively just extends the password by several characters that the user doesn't need to memorise. Absence of salt means that dictionaries (even clever storage-optimised dictionaries like rainbow tables (most of the implicit content of which is randomish strings that aren't actually so useful, the win is by limiting what that randomness might be in order to maximise the chance of covering an actually-used password)) can be shared for every account. Common salt means that the dictionaries can be shared for all those who share that common salt (at that particular point in time). So what you really want is just to have as many of your users having different salt. That is a *statistical* requirement, not a *cryptographic* one. So a shitty (i.e. typical libc srand(time(0));rand()) random number is perfectly good enough to achieve that. Just make it long enough that collisions are uncommon so dictionaries cannot be effectively leveraged.

      User ID, user name, and timestamp of account creation are presumably constant for the user, which means that if a group of people find themselves in a big cluster of collisions on the seed value, they're stuck with being easier as a target. Because that is clearly not better than just a shitty (as above) random number, it matters not whether it's actually worse (which I have a gut-feel it is), one may as well use a known-good-enough shitty random number source.
      --
      Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves