Slashdot Mirror


New Online MD5 Hash Database

Gravix writes with a shameless plug for his new site "Sporting over 12 million entries, project GDataOnline is one of the largest non-RainbowTable based MD5 crackers on the internet. The database spans over 7 languages, 35 topics, and contains common mutations to words that include numbers and capitalization. Average crack time for 5 hashes: .04 seconds. No more waiting weeks for your results!" Shameless plug aside, the site still seems worth a closer look.

295 comments

  1. Slashdot by charon_1 · · Score: 0, Funny

    It doesnt have the hash for slashdot :( 4e9fd9f4624c02685096769364a81d95

    1. Re:Slashdot by keeleysam · · Score: 3, Funny

      RESULTS:
      Hash Pass
      4e9fd9f4624c02685096769364a81d95 slashdot

      Yes, it does.

      --
      Nothing for you to see here, Please move along.
    2. Re:Slashdot by Anonymous Coward · · Score: 1, Funny

      Hands up everyone who could've told that from memory.

    3. Re:Slashdot by speights_pride! · · Score: 1, Funny

      Please stop posting my passwords here! Thanks.

    4. Re:Slashdot by `Sean · · Score: 1

      12345? That's the kind of combination an idiot would have on their luggage.

    5. Re:Slashdot by Lotharus · · Score: 1

      Call my secretary. Have her change the combinations on all my luggage.

  2. First Prime Factorization Post by 2*2*3*75011 · · Score: 1, Funny

    Database contains 12,288,524 = 2*2*31*113*877 unique entries.

    1. Re:First Prime Factorization Post by Anonymous Coward · · Score: 0

      Neat. Your username is the prime factorization of your UID. How very clever. I applaud you. It seems most folks just don't put this kind of effort into their trolling anymore.

    2. Re:First Prime Factorization Post by Anonymous Coward · · Score: 0

      And it only took you a month to notice him.

    3. Re:First Prime Factorization Post by 793528 · · Score: 1

      Estimating a uid isn't that tough.

      --
      Be one with your UID.
  3. quick by Lehk228 · · Score: 5, Funny

    Quick! everybody go test your password security by sending it to a random web site

    --
    Snowden and Manning are heroes.
    1. Re:quick by AndreiK · · Score: 1

      Don't worry - people are nice these days, they can forgive an honest mistake!

    2. Re:quick by qaq · · Score: 2, Interesting

      Y it's so unsecure because there is this public database of IPs availible so they won't have to try many hosts to find the one with your password.

    3. Re:quick by TheRaven64 · · Score: 2, Informative

      It didn't have my password (hash: ae5799ed7235ff7d43a19073c74f4667), which was quite a surprise. It's the deeply insecure password I use for boxes with no remote services enabled (systems in VirtualPC, my Windows laptop) - it's only useful to a local attacker, and they have much easier ways of gaining access.

      --
      I am TheRaven on Soylent News
    4. Re:quick by alnjmshntr · · Score: 1

      I was thinking the same thing on one of our test systems, and then I remembered that we modified to hash the username and password, which pretty much defeats this database.

      I don't know much about encryption, but I'm pretty sure windows doesn't just hash the pwd.

      --
      If I had created the world I wouldn't have messed about with butterflies and daffodils. I would have started with lasers
    5. Re:quick by Guspaz · · Score: 1

      Assuming that Windows even uses MD5, it probably uses a salt in the hashes.

  4. oh, i get it! by Anonymous Coward · · Score: 5, Funny

    6436a55a08760c5b94dbed4476f83fcd

    1. Re:oh, i get it! by Anonymous Coward · · Score: 0

      Uh, I don't get it.

      What does

      6436a55a08760c5b94dbed4476f83fcd

      translate to?

      Using the secret decoder did not work for me.

    2. Re:oh, i get it! by Anonymous Coward · · Score: 0

      ecb27bf66c32a67151e16bf55bcace25

    3. Re:oh, i get it! by tpearson · · Score: 0, Offtopic

      first post

    4. Re:oh, i get it! by isorox · · Score: 2, Insightful

      8acb583ce572bbdd4d8cd3375fba65f9

    5. Re:oh, i get it! by Matilda+the+Hun · · Score: 5, Funny

      8acb583ce572bbdd4d8cd3375fba65f9
      --
      This post may be the personal opinion of me and noone else, but it's more likely to be random characters.


      Someone mod his sig +5 Insightful.

      --
      Tluin natha Linux xxizzuss uriu olt bwael mon'tun.
    6. Re:oh, i get it! by Saeger · · Score: 3, Informative

      $ echo -n "first post" | md5sum
      6436a55a08760c5b94dbed4476f83fcd -

      --
      Power to the Peaceful
    7. Re:oh, i get it! by caffeinex36 · · Score: 4, Funny

      Be..........sure..........to ...........drink .........your ovaltine? SON OF A BITCH!

    8. Re:oh, i get it! by Anonymous Coward · · Score: 0

      Can anyone explain that one? I tried some variations of echo -n "you fail it"|md5sum, but that doesn't seem to be it

    9. Re:oh, i get it! by germanStefan · · Score: 1
      This highlights a huge security flaw in many website logins. To many websites just md5($pass) the password and stick it into the database. A malicious hacker could then easily copy and paste it into the website and voila access granted.

      A more secure system also has a salt value (generated randomly everytime the password is changed by a user) so that the resulting md5 hash is md5($salt.$password). This adds randomness and length to an otherwise possibly short password. I'm no security expert, but I just pasted in a few of my "passwords" in mysql tables which were generated with md5 and the website didn't find any that were generated with the salt. Older ones before I knew about the idea of salt were cracked instantaneously....so hope someone learns a lesson here

    10. Re:oh, i get it! by Kadin2048 · · Score: 1

      This might be an extremely ignorant question, but how can that work?

      Perhaps I misunderstand, but I thought the point of the website's hash table was so that when a user wants to log in later on, you hash the new entry attempt, and compare it to the stored hash. If they match, access granted.

      If you included some random salt in the original hash, how would you ever compare it to an entered password attempt later down the line, without also storing a list of the salts?

      And if you store a list of the salts, how are you creating any additional security? The only additional piece of information you're adding to the hash cannot be secret...so what is its purpose?

      --
      "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    11. Re:oh, i get it! by stevey · · Score: 1

      You're right you're storing the extra "salt" in the database, kinda like this:

      username VARCHAR( 16 )
      salt VARCHAR( 2 )
      password VARCHAR( 32 );

      This should gain you increased security because it means that a password hash is "MD5(salt+password)" - and the hash isn't known.

      However it doesn't gain you much if your database is compromised and all the salt's can be stolen. Although you say the salt "cannot be secret" I don't see that, it should be purely used internally...

      (On plus is that multiple users with the same password will have a different hash in the database).

    12. Re:oh, i get it! by HermanAB · · Score: 1

      Frist psot of course...

      --
      Oh well, what the hell...
    13. Re:oh, i get it! by Bitsy+Boffin · · Score: 1

      The salt doesn't matter if it gets known, for the typical attacks.

      The only reason you'd need the salt in an attack is if you needed to verify a supplied password against the stored hash (ie, you stole the DB and were setting up a phising scam or something).

      the attach that this article is about is for working out the original source password given a hash by havign a huge database of word -> hash mappings. A salt makes that impossible because even if you know the salt, and the md5 that was generated in conjunction with that salt, you don't know what the md5 would have been without that salt. So you have no md5 to lookup in your big database to find the (likely) original word.

      --
      NZ Electronics Enthusiasts: Check out my Trade Me Listings
  5. Downloadable database form? by 5n3ak3rp1mp · · Score: 5, Interesting

    Does anyone know how to get a hold of a database such as this? As part of our IT auditing I'd like to be able to do a join of our md5-encoded user passwords (no salts or anything) with this to see whose password is insecure... yeah, that's it...

    1. Re:Downloadable database form? by Janitha · · Score: 5, Informative

      You can create it, actually if you asked that a few months ago I had 100GB worth of md5 0-8 alpha-ALPHA-num every combination for sale (which I later made free if you sent me DVD's) but I deleted since no one was much interested and it was much needed space for other stuff. I used rainbowcrack (http://www.antsight.com/zsl/rainbowcrack) for some reason the linux client seems to work much faster than the windows one (although it made no sense to why)

    2. Re:Downloadable database form? by bobbozzo · · Score: 3, Insightful

      One of the vendors at DefCon this year was selling them.

      Try googling for Rainbow Tables.

      --
      Nothing to see here; Move along.
    3. Re:Downloadable database form? by Anonymous Coward · · Score: 0, Funny
      Create a program to hash out a dictionary file. You can get dictionaries for many different languages. It probably wouldn't take too long to get 12 million hashes.

      6436a55a08760c5b94dbed4476f83fcd is funny though. Wow.

    4. Re:Downloadable database form? by Janitha · · Score: 4, Informative

      With multiple programs working on seperate parts (assuming you broke your whole project into many tables) it can be done pretty fast. Specially if you have access to many computers. The rainbowcrack will automatically pick up and resume work if interupted in the middle, and skips over if the asked table is already created, so its perfect for the job of spanning across multiple machines.

    5. Re:Downloadable database form? by rd4tech · · Score: 4, Interesting

      Recently I did a project for crunching out MD5 hashed on windows and linux. Linux was faster by 1/3 and mainly because of less time was spend waiting for the system to finish the i/o part.

    6. Re:Downloadable database form? by pAnkRat · · Score: 4, Insightful

      Just out of interrest, why would you store the password for a user as (pseudo code follows)

      md5(pw);

      and not

      md5(username + pw);

      Salting the the hash with a variable (here: username) helps preventing wide scale probing with rainbow lists in the event the DB gets "stolen".

      --
      we need an "-1 Plain wrong" moderation option!
    7. Re:Downloadable database form? by TheRaven64 · · Score: 1

      You might also want to invest in something like the Soekris VPN1401 - a PCI board that can (among other things) do MD5 and SHA1 hashes at 325 to 360 Mbps. OpenBSD supports hardware crypto on these devices, so you can get a decent throughput. A few machines with these connecting to a decent database server to store the results should be pretty nippy.

      --
      I am TheRaven on Soylent News
    8. Re:Downloadable database form? by Thundersnatch · · Score: 5, Informative

      It's called a password "salt", and many applications use them. It's much better to use a large random value stored in the clear than the username.

      Microsoft, of course, is screwed by the need to provide backward compatibilitty, and does not salt the (MD4-based) NTLMv2 hash stored on Windows systems. They encrypt the whole hash database instead to prevent offline attacks, but this is ineffective as the decryption key is also "hidden" on the system's disk unless you want requrie a diskette/CD/floppy at boot that contains the decryption "syskey".

    9. Re:Downloadable database form? by 5n3ak3rp1mp · · Score: 1

      You're absolutely right. Or at least, that's a better alternative.

      Unfortunately, I did not design the system. I would not have designed it that way. I probably would have used SHA-1 too.

      Which is why I'm considering quitting so I actually get to design stuff properly...

    10. Re:Downloadable database form? by NynexNinja · · Score: 1

      selling them? http://rainbowtables.shmoo.com/ was giving out free torrents at defcon ... Its something like 30-60GB tho so watch out.

    11. Re:Downloadable database form? by hey · · Score: 1

      I prefer Linux but too.
      But you might want to check out overlapped I/O in Windows.

    12. Re:Downloadable database form? by UnrefinedLayman · · Score: 1
      I probably would have used SHA-1 too.
      Please read: http://www.rsasecurity.com/rsalabs/node.asp?id=283 4. SHA-1 is on its way out.
    13. Re:Downloadable database form? by rd4tech · · Score: 1

      Overlapped? I'm not quite following you.

      When doing the testing I disabled every service not needed by default for the operating system to work. Including sound, network, logging, etc.

      I don't think there was anything causing much disturbance on the I/O side.

    14. Re:Downloadable database form? by CTachyon · · Score: 1

      FYI, Overlapped I/O is an API for Windows programmers. It's vaguely similar to open(O_ASYNC) and SIGIO in *nix, if you squint your eyes a bit. None of which means a damn thing if you're not actually writing the code, but using someone else's.

      --
      Range Voting: preference intensity matters
    15. Re:Downloadable database form? by Anonymous Coward · · Score: 0

      It is called asyncronous data access, even in the Windows world. Just check the .NET MSDN pages on "Asynchronous File I/O"

      I think "overlapped" is what they used to call it in Win32 API and it originates from the Win16 API on Windows 3.x... Kind of dated.

    16. Re:Downloadable database form? by bobbozzo · · Score: 1

      Yes. Selling them.

      I'm back at my desk and found the flyer.

      RainbowTables.net

      --
      Nothing to see here; Move along.
    17. Re:Downloadable database form? by CTachyon · · Score: 1

      SHA-1 is still less broken than MD-5, but both are still acceptable for password hashing. The new attacks are both collision attacks [attacker creates A and B such that H(A)=H(B)] and not preimage attacks [attacker creates A such that H(A)=H(S), where S is unknown to the attacker but H(S) is known]. While the new attacks are important to anyone using digital signatures (e.g. PGP) to sign documents created by others, they're still considered rather solid for password hashing. So what if a user can create two passwords that both hash to the same SHA-1 output? Now they have two passwords to get into their own account, but it doesn't help them get into anyone else's.

      --
      Range Voting: preference intensity matters
    18. Re:Downloadable database form? by Anonymous Coward · · Score: 0

      Very thoughtful and well-thought-out reply. Thanks.

    19. Re:Downloadable database form? by theonetruekeebler · · Score: 1
      The most obvious reason I can think of is that under Unix it is trivial to change a username as everything in the system is done by the uid. If the username is used for password salt, a change to the username would require a change to the password.

      As was mentioned before, a string of random characters, stored in the clear, makes better salt.

      On a completely unrelated note, this is my 1000th post to Slashdot. It's a dubious accomplishment: I'm rather proud of some of the things I've written here, but the effort to create 1000 Slashdot posts is probably greater than the effort to write a textbook or a novel.

      --
      This is not my sandwich.
    20. Re:Downloadable database form? by Harik · · Score: 1
      Uh um.
      On a completely unrelated note, this is my 1000th post to Slashdot. It's a dubious accomplishment: I'm rather proud of some of the things I've written here, but the effort to create 1000 Slashdot posts is probably greater than the effort to write a textbook or a novel.

      Don't be too proud of this one, you're 100% wrong. Only the administrator can change the username for a given UID. Even changing a password requires administrator privs. (Which is why /bin/passwd is suid root)

      The site couldn't even crack 'god', one of the most common passwords. And for good reason, too.

      The unix standard has been random salted DES for years. Switching to MD5 kept that cleartext salt in the format, but upgraded it from 2 bytes to 8 (2^12 -> 2^48). That's pretty much beyond the ability of any database to store. (256 trillian permutations per password)

      NT, however, is hosed.

    21. Re:Downloadable database form? by theonetruekeebler · · Score: 1
      Don't be too proud of this one, you're 100% wrong.

      *Sigh*. At no point did I say a user could rename his account. I said that changing a user's name under Unix was trivial, and it is---generally a matter of editing one or two textfiles. If an administrator needs to change the user's name (to correct the spelling, add disambiguation, meet new departmental standards) and if (as the parent post seems to imply) the password algorithm is using the contents of the name field as salt to md5, the user's old password is broken.

      So I am 100% wrong only if your assumption that I think users can change their own account names is right. Unfortunately, it is 100% wrong. Neener neener neener.

      A second weakness of the proposed system is that if the username is known to the cracker, then the salt is also known, again making dictionary attacks viable.

      --
      This is not my sandwich.
    22. Re:Downloadable database form? by CTachyon · · Score: 1

      Actually, Overlapped I/O is specific to the NT kernel 4.0+, although Windows 95+ emulates it at the API level (except for serial and parallel port I/O, where it's actually native).

      See the MSDN articles on struct OVERLAPPED and CreateFile(FILE_FLAG_OVERLAPPED) .

      --
      Range Voting: preference intensity matters
  6. Hmmm... by mg2 · · Score: 5, Insightful
    Seems like using salted MD5 hashes would render this kind of stuff totally useless.

    ...You all use salted md5 hashing in your applications, don't you?

    1. Re:Hmmm... by FLAGGR · · Score: 4, Funny

      I prefer pepper.

    2. Re:Hmmm... by Anonymous Coward · · Score: 0

      Umm. As someone new to cryptology...

      What's "salted"?

    3. Re:Hmmm... by Anonymous Coward · · Score: 2, Informative

      I thought I might try explaining it, but Wikipedia would probably do a better job:

      http://en.wikipedia.org/wiki/Salt_(cryptography)

    4. Re:Hmmm... by Anonymous Coward · · Score: 1, Funny

      Salt is a term used for ionic compounds composed of positively charged cations and negatively charged anions, so that the product is neutral and without a net charge. These ions can be inorganic (Cl-) as well as organic (CH3-COO-) and monoatomic (F-) as well as polyatomic ions (SO42-).

    5. Re:Hmmm... by jurt1235 · · Score: 3, Informative

      MD5 is a hashing method, and ofcourse you can look up the hashes again. It is just a quick and dirty way of encoding your passwords in php, or to check if a file is really that file which you were expecting. It is not for real password encryption use.

      Anyway: MD5 hashes over a certain dataset are not unique. Two datasets can result in the same MD5 hash, assuming a fixed has length. This database could point those out too.

      As last remark: This kind of database use has been done before by chess engines. By just storing most succesful board setups, the next moves could be executed more effectively and a lot faster.

      --

      My wife's sketchblog Blob[p]: Gastrono-me
    6. Re:Hmmm... by Nailer · · Score: 1

      Most Linux distro that use MD5 salt the hashes in /etc/passwd or LDAP.

    7. Re:Hmmm... by Anonymous Coward · · Score: 2, Funny

      OMG then we would just make a database of salted md5 hashes!! YOU CAN'T WIN VERSUS THE HAX0RS.

    8. Re:Hmmm... by bsdrawkcab · · Score: 4, Interesting

      You jest, but I seem to recall "pepper" being used to describe a related scheme under which the salt is secret and has a relatively small domain (but large enough to make dictionary attacks much harder). The idea was that if you provide the right password, the computer can exhaust the possible pepper values until it gets a match, but the correct value never needs to be stored.

      Sound familiar to anyone else? Anyone know if it's used in practice?

      --
      Consistency requires you to be as ignorant today as you were a year ago. -Bernard Berenson
    9. Re:Hmmm... by Tobbe+Starfield · · Score: 3, Informative

      If you just store the hashes of passwords they are vulnerable to dictionary attacks. If you also add some random data, "salt", to each password before hashing, you get a salted hash. Even if you store the "salt" and salted hash right next to each other, it gets much harder to attack. (Of course this may well have other applications than password storage.)

    10. Re:Hmmm... by baadger · · Score: 4, Interesting

      function pepperMatch(password, hash) {
      var pepper = ['po', '3g', '37', 'ax'];
      var p;
      for p in pepper {
        if (md5(pepper[p] + password) == hash)
          return true;
      }
      return false;
      }

      Beyond the obvious downside to this (4 times the CPU time for legitimate matches) the advantage is obviously that the cracker has 4 times the bruteforcing to do. But if your security has been comprimised enough to allow someone to find out this hash then you probably have bigger things to worry about.

      Maybe tricks like these will come into their own once people realise just increasing hash length or changing the function isn't going to make them any more secure when users still aren't using 'good' passwords.

      If you think about it hashing your passwords in a database is almost an admittance either that 1) you're database will probably be comprimised or 2) you're users shouldn't trust you. I wonder if it's possible to grep the likes of MySQL's storage files for MD5 hashes (thereby bypassing the databases authentication)?

    11. Re:Hmmm... by karmatic · · Score: 2, Informative

      > I wonder if it's possible to grep the likes of MySQL's storage files for MD5 hashes (thereby bypassing the databases authentication)?

      Yes, but you need shell access to do it.

    12. Re:Hmmm... by clary · · Score: 1

      If you think about it hashing your passwords in a database is almost an admittance either that 1) you're database will probably be comprimised or 2) you're users shouldn't trust you. I wonder if it's possible to grep the likes of MySQL's storage files for MD5 hashes (thereby bypassing the databases authentication)?

      It is mostly 2). Your users shouldn't trust you, nor should you trust yourself, unless "you" is truly a single person. Any system that has users logging into it is probably accessible to multiple insiders. Having cleartext passwords in the database opens up the evil possibility of an insider stealing passwords and impersonating the real user. Now maybe that would not be a big deal on SlashDot, but on a banking or brokerage site...


      If a site can give you your forgotten password (as opposed to just resetting it for you), then don't use that site for anything you care to keep secure.

      --

      "Rub her feet." -- L.L.

    13. Re:Hmmm... by Anonymous Coward · · Score: 0

      You obviously work in Customer Support. How's the weather in Redmond today?

    14. Re:Hmmm... by Goaway · · Score: 1

      > If you think about it hashing your passwords in a database is almost an admittance either that 1) you're database will probably be comprimised or 2) you're users shouldn't trust you.

      Why yes, thank you, Captain Obvious.

    15. Re:Hmmm... by Tony+Hoyle · · Score: 1

      Most Linux distro that use MD5 salt the hashes in /etc/passwd or LDAP.

      Nobody puts passwords in /etc/passwd any more. They go in /etc/shadow.

      Alternatives exist (Kerberos, Samba, LDAP) but they're nowhere near as widespread.

    16. Re:Hmmm... by monkeydo · · Score: 1

      Two datasets can result in the same MD5 hash, assuming a fixed has length.

      For any hash function which produces a fixed length hash, there will be an infinite number of inputs that produce the same result. The usefulness of a hash function depends on the difficulty in finding an input that generates a particular output. Note that to defeate the function, you don't have to come up with the "right" input, just any input that returns the same hash.

      --
      Si vis pacem, para bellum
      The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
    17. Re:Hmmm... by hackstraw · · Score: 2, Interesting


      Am I behind the times in modern security?

      AFAIK, for years all *NIX-like systems put their hashes in a root-only readable file (/etc/shadow), and its a prerequisite to either hack root or exploit some rare and obscure local exploit that may dump the contents of the shadow file (core dumps, or whatever).

      Now, as far as I am concerned. Any system that has been root compromised, then all user accounts are assumed to be compromised as well. Instead of only wasting time trying to brute force passwords now that you can access the shadow file, you can add a new account for yourself, modify an existing account with the 'passwd' command, trojan an existing binary (not very useful since most everybody checks their system binaries, right???), or do whatever people do when they root a box (usually something really evil like install an IRC bot).

      I've never understood fascination around password security, when they are probably the least exploited weakness in computers since WOMPR was broken into with the 'joshua' password.

      I've used passphrase protected ssh keys instead of passwords for years. If I had more informed users I would not even allow passworded access via ssh, but that would probably cause me more headaches than its worth. Also, on a side note, does anybody know why the ssh daemon cannot tell if a public key access to the system has been protected with a passphrase? I understand why there are passphraseless keys, but it should be known to the daemon and possible to reject non-protected public keys.

    18. Re:Hmmm... by Anonymous Coward · · Score: 0

      Lick my cation and anion-coated chocolate balls.

    19. Re:Hmmm... by stewby18 · · Score: 2, Informative

      If you think about it hashing your passwords in a database is almost an admittance [tha] you're database will probably be comprimised

      No, it's a recognition of the fact that it's at least theoretically possible that your database might be compromised at some point in the future. And anyone who isn't an idiot will design their systems in such a way as to minimize the damage that can be caused by a single point of failure. That's not an admission of incompetence, it's plain common sense.

    20. Re:Hmmm... by sineltor · · Score: 1

      Mod parent up.

      There was an old view in the security world about making security like a nut, hard shell on the outside but once you're in access becomes a piece of cake....

      This is well and good in the academic world where people see crypto as *100%* secure but in the real world with all the vulnerabilities in software these days minimising damage from attacks is just as important as defending the network borders.

      --
      'No publisher will ever pay you enough to successfully sue them' - Dave Sim
    21. Re:Hmmm... by CTachyon · · Score: 1

      A passworded SSH key is just a passwordless key that's been symmetrically encrypted with a passphrase, and it has to be decrypted on the client side before it can be used. The SSH protocol could've added a bit to tell the server that the key started off encrypted, but the client could just as easily have been patched to always tell it "true".

      --
      Range Voting: preference intensity matters
    22. Re:Hmmm... by hackstraw · · Score: 1

      A passworded SSH key is just a passwordless key that's been symmetrically encrypted with a passphrase, and it has to be decrypted on the client side before it can be used. The SSH protocol could've added a bit to tell the server that the key started off encrypted, but the client could just as easily have been patched to always tell it "true".

      Yes, I realize that it is not a simple problem to overcome because once the key is decrypted with a passphrase, it is the same as a non-passphrase protected key.

      I'm no crypto expert, but having something like the first byte of the public key that indicates the passphrase state of the private key would be great. There seems to be some way to overcome this issue. I've heard of sites that do not allow any keyed access to their sites because of the lack of assurance that a passphrase was used to protect the user's local private key.

      It seems like the information could be signed some way like an SSL cert, but I could be wrong out of not knowing enough about the low level aspects of ssh.

    23. Re:Hmmm... by after+fallout · · Score: 1

      Very few see it as 100% secure in the academic crypto world; it is more like 56bit secure (can be cracked in under 3 minutes), 128bit secure (takes a long time to crack), 256bit secure (takes a very long time to crack), and more.

      The closest you can get to 100% secure is to have your key as long as your message, and to destroy the key when you have encrypted the message and the reciever has the key (in the academic world we would call these one time pads). But even these are not 100% because you still need to worry about the key.

    24. Re:Hmmm... by baadger · · Score: 1

      What I really mean is your users don't trust you enough not to take a casual glance at their passwords if you're sat their twiddling your thumbs. It really depends on the context if that is relevent. The client can't tell if you're hashing their passwords server side anyway (unless it's hashed client side) so establishing trust by hashing is irrelevent.

    25. Re:Hmmm... by baadger · · Score: 1

      I never intended, nor did I say that it was an admission of incompetance. All I mean is it is a very common method people use thinking it'll solve the problem, when infact it does not.

      In the case of any vanilla unseasoned hash you are just praying noone has managed to put together a complete hash map, i.e.00000000000000000000000000000000 -> ffffffffffffffffffffffffffff in the case of MD5 (The chances of this are fairly small as we can see from this article we have only managed 12M/2^128), or found a way to produce a collision (for which now it very feasible for MD5). Relying on this would be stupid.

      The real security benefit from salting isn't that the cracker has to rebuild his hash mapping. It's that it forces them to find a collision that meets certain parameters (without revealing anything about the actual plaintext). Once somebody has your salt/pepper procedure they can apply the same attacks as in my previous paragraph.

      However you can do one better by including the plaintext's length in the hash procedure: H(salt + optional_pepper + length(plaintext) + plaintext).

      Unless you do this then plain salt and pepper alone is going to leave you buggared if someone gains readonly access to your source code and/or database (pretty easy in a shared server environment).

    26. Re:Hmmm... by Tekgno · · Score: 1

      The pepper isn't so much another barrier as a knee high fence, all it can do is slow an attacker down marginally.

    27. Re:Hmmm... by Paul+Crowley · · Score: 1

      This is called "key strengthening". It has its advantages, but I prefer "key stretching", the technique of iterating hashes I linked to earlier; it's harder to parallelize the attack and more predictable how long it will take. Google for "schneier low-entropy".

    28. Re:Hmmm... by Crispy+Critters · · Score: 1
      "Beyond the obvious downside to this (4 times the CPU time for legitimate matches) the advantage is obviously that the cracker has 4 times the bruteforcing to do."

      That is the whole point. The CPU work that needs to be done to check passwords at login is negligible. We can make that take orders of magnitude longer, and no one will even notice. Making the brute forcing take orders of magnitudes longer will gain us a few years before we have to move to using retinal scans or 50 character passphrases.

      This is in essence already part of normal Unix passwords. The password encryption scheme was intentionally made slow to thwart brute force attacks. Adding pepper just recalibrates the slowness factor to be appropriate for modern hardware.

    29. Re:Hmmm... by drsquare · · Score: 1

      What the hell is salted MD5 hashes? I sort of understand what hashes are, but salted?

    30. Re:Hmmm... by Nailer · · Score: 1

      Indeed, /etc/shadow. Had a braino :^).

    31. Re:Hmmm... by Atryn · · Score: 1
      If a site can give you your forgotten password (as opposed to just resetting it for you), then don't use that site for anything you care to keep secure.
      Including your password!!! I.e. - using the same password at a site like this as you use elsewhere.

      I hate when I discover a site like this. I mean how do I have the time to check every site's lost password system??? I recently got this from Hertz. At their web site I had forgotten my password and it emailed it to me in cleartext! Arrghhhh....

      --
      Come play Moral Decay!
    32. Re:Hmmm... by 6th+time+lucky · · Score: 1

      My phone company *insisted* on emailing out the bill with my password on it to make it easier... What the f*cking dum shit piss pot system is that???

      I politely enquired about the fdspp system and was told is was implimented over the old system that didnt include the password based on user requests... to make it easier.

      Their emails went along the lines of
      1) go to our billing website here
      2) enter your accound code "123456" (without the quotes dumass)
      3) enter your password "fluffy"

      To make matters worse, the sysadmins or the monkeys i was talking to, didnt seem to understand that email is not secure... and that sending out passwords is a bad idea.

      I was going to change providers immediatly, but found out my next best choice was infact re-selling the same product just with 8Mb DSL... now all i need is the cash...

    33. Re:Hmmm... by CTachyon · · Score: 1

      And who would do the signing? Would you ship your private keys over the Internet to a "trusted" 3rd party clearinghouse (e.g. Verisign) to let them digitally sign a little certificate verifying that the private key was encrypted? Anything short of that can be faked trivially.

      --
      Range Voting: preference intensity matters
    34. Re:Hmmm... by hackstraw · · Score: 1

      And who would do the signing? Would you ship your private keys over the Internet to a "trusted" 3rd party clearinghouse ...

      Its all about who you trust. Do you trust that green and white piece of paper can buy you something?

    35. Re:Hmmm... by CTachyon · · Score: 1

      You're missing the point. The whole point of having a public/private keypair is that the private key never leaves the client's computer. Any crypto system that breaks that rule is less secure than one that follows it, because it has more points of failure. It makes far more sense to just patch ssh-keygen to require an affirmation in triplicate that the user understands the implications of having an unpassphrased private key. A mandatory policy approach is wrong for this situation, and for multiple reasons.

      --
      Range Voting: preference intensity matters
    36. Re:Hmmm... by hackstraw · · Score: 1

      You're missing the point. The whole point of having a public/private keypair is that the private key never leaves the client's computer.

      I don't believe I'm missing the point anymore than everyone else is. As it stands, the most prevalent way to "identify" someone's identity on computer systems is with a username and password. Its also worth noting that SSL certs are signed by a third party and they seem to be trusted by most people, regardless if that trust is valid or not, it really hasn't been challenged.

      I'm not feeling well enough to think much more. I just would like to have a fairly secure yet easy method for authentication on computer systems. The best approach I've found thus far is using ssh and a passphrase protected private key that is unlocked once I log into my local machine, and from there I am able to securely access any number of machines without worrying about passwords or whatever. As I said, the downside of this method is that there is no way to ensure that the remote user has their private key adequately protected, and some sites have a policy to reject all authentication based on keys in favor of username/passwords which is not really any more secure than an unprotected private key.

      EOF

    37. Re:Hmmm... by CTachyon · · Score: 1

      SSL works by sending the PUBLIC key to a trusted 3rd party and letting them sign it. (They are generally willing to do this if you pay them $100/year or so for the trouble.) Sending the PRIVATE key would be suicide. Note that SSL private keys are, just as with SSH, normally stored unencrypted on the hard drive of whatever computer normally uses that key. This is mandatory in most situations because the SSL application (Apache, Exim, whatever) must start up without human intervention. If the SSL libraries (stupidly) required the private key to be encrypted, then you'd just store the passphrase in plaintext on the server, which isn't the least bit more secure. Likewise, SSH is commonly used in automated scripts to log into remote computers (e.g. a user doing a scheduled backup of his remote home directories), and any automated use of SSH will have the same troubles.

      You're quite mistaken if you think that username/password is more secure than public/private key. Since SSH refuses to use a private key with insecure file permissions, only a root compromise on the client machine can reveal the private key. However, it's revealed whether or not it has a passphrase, since root can just snoop the memory of the SSH process to obtain the decrypted key, keylog the user's TTY and steal the passphrase, trojan the SSH program to stash a decrypted copy somewhere, etc., etc. All those same flaws apply to username/password as well, except that now the user is vulnerable to a root compromise on any of the computers he logs in via, rather than just his home machine. If he's smart (most users aren't), he'll have a different password for each computer, and hopefully it'll just be his password on your computer that's leaked.

      --
      Range Voting: preference intensity matters
  7. Hash Counter by Lord+Byron+II · · Score: 4, Funny

    This is fun.. watching his hash counter go up. It was at 32 when I first saw it, which means that near all of the increase over the next few days can be attributed to the /. effect (assuming he doesn't get posted to some other major site).

  8. Doesn't seem very useful by VeryProfessional · · Score: 5, Insightful

    Apart from the fact that this site is somewhat morally questionable, it doesn't seem to work very well. I inserted a number of hashes for common first names and dictionary words, and none of them returned a hit. If the database doesn't even cover common stuff such as this, what is it really good for? Really, 12 million hashes out of a space of 2^128 is truly miniscule.

    1. Re:Doesn't seem very useful by kasperd · · Score: 5, Insightful

      I inserted a number of hashes for common first names and dictionary words, and none of them returned a hit.

      You wouldn't by any chance be using the md5sum command line utility and typing a newline after the word? I just tried my own name, which turned out to be in the database. Could you give just a few examples of the hash values you submitted, and the word you expected it to return?

      --

      Do you care about the security of your wireless mouse?
    2. Re:Doesn't seem very useful by VeryProfessional · · Score: 4, Informative

      You wouldn't by any chance be using the md5sum command line utility and typing a newline after the word? I just tried my own name, which turned out to be in the database. Could you give just a few examples of the hash values you submitted, and the word you expected it to return?

      Oops, right you are, that's exactly what I was doing... tried the same words with echo -n and they were in fact in the database.

      /me wipes egg off face

    3. Re:Doesn't seem very useful by Anonymous Coward · · Score: 0

      ... very professional!

    4. Re:Doesn't seem very useful by blowdart · · Score: 2, Interesting
      It certainly didn't get my passwords, but I was less amused by the popup attempts, for both onLoad and the getFocus event for the text box where you're supposed to type. Certainly felt slimey, no wonder the submitter was happy to try to get his own site slashdotted, the popups for casinos (well I had to see what they were!) no doubt bring in some pocket money.

      It also seems very limited to dictionary words, there's no attempt at some useful things like IP addresses (I've seen a few BBSes who don't publish IPs, but instead publish hashes).

    5. Re:Doesn't seem very useful by DRobson · · Score: 1
      Really, 12 million hashes out of a space of 2^128 is truly miniscule.

      Considering the average persons password, and the fact a large number of applications wouldnt use salts, I'd say you'd be able to crack a good 3/4 of the passwords out there. In fact, 12 million is a damn side larger than I'd expect is needed for password 'auditing'. Never underestimate the amount of craptacular passwords out there.

    6. Re:Doesn't seem very useful by H0ek · · Score: 1
      If you're using md5sum, it helps if you don't include the newline, like this:
      echo -n phrack | md5sum
      returns:

      f6174179c90c0366b99d7a1d91cf6f4a

      Which successfully performs the lookup for me.
      --
      H0ek
      Think you're smart? Prove you've got brains!
    7. Re:Doesn't seem very useful by Cellshade · · Score: 1

      Why do you spread lies?

      There are no javascript events tied to the text input boxes and there are no popup windows on the site.

      Maybe you should check your system for spyware.

    8. Re:Doesn't seem very useful by blowdart · · Score: 1
      And maybe you should declare your interest, liar.

      Look at the source, which loads in http://ads.kmpads.com/pcode.js. Look in there and there's a hook into document.onClick(). As for the popup on load, I'm sure everyone can see the information bar in Firefox, or IE already.

    9. Re:Doesn't seem very useful by Tony+Hoyle · · Score: 1

      ..so the way to beat this is to put a newline in your password (which is possible on many systems).

    10. Re:Doesn't seem very useful by arkanes · · Score: 1
      The page as currently shown has no popups. In fact, it has no javascript of any kind. There are text ads at the bottom, which may injected the javascript somehow, or there may have been a rotating banner ad that did it that was since removed, or it may have been on the page and was now removed. Or you may have spyware thats injecting the JS (although that would be stupid, since anything that could do that could spawn the windows directly).

      As an interesting aside, check out the numbers on the site hosting that Javascript for a great example of why people spam. 1.5% response rate, compared to 13% for Google, but with 1/55th the cost, it (claims) greater cost effectiveness.

  9. So what? by kasperd · · Score: 5, Informative

    Any system using plain md5 to hash passwords is broken anyway. Include a salt - and any database over hashes will become useless. Besides if people choose good passwords, they are most likely not in the database. That is already two reasons why people should be protected, do we need anymore?

    For many other uses of cryptographic hashes the input is much more than a single word, and typically you don't really worry about keeping the input a secret anyway.

    --

    Do you care about the security of your wireless mouse?
    1. Re:So what? by Sithgunner · · Score: 1

      Problem thinking like only proper thinking people exists on earth as you want to describe...

      I bet too many passwords on machines accessible in public have weak passwords.

      It's not like everybody is just as security alerted as you are and you can't just throw the topic because you can think of a method to protect.

    2. Re:So what? by Anonymous Coward · · Score: 0

      Not necessarily, since the majority of systems include the username as part of the password hash. That makes things a little more unique...

    3. Re:So what? by kasperd · · Score: 1

      you can't just throw the topic because you can think of a method to protect.

      I gave not one, but two ways to protect against this. One was the user picking a good password, the other was a sensible software design. That means you will need to combine a stupid developer with a stupid user if you want to be vulnurable.

      --

      Do you care about the security of your wireless mouse?
  10. Re:OT but... by Anonymous Coward · · Score: 0

    Google is your friend!

    "try the veal"

  11. wow by Anonymous Coward · · Score: 1, Insightful

    They must be smoking some dope ass crack if they think they have lots of common permutations of dictionary words covered. Try fcaf8cb5751b2995c95f6c8021584eff (h3ll0) or 50c20343d45744b1aa36ace8c04c700a (th3r3). Is there anything simpler in terms of commons words with obvious numeric substitutions that it actually gets?

    1. Re:wow by FLAGGR · · Score: 3, Informative

      thats why the made a form for you to add words. Crazy ain't it. Although they should've made some automatic leetspeak adding script.

    2. Re:wow by Anonymous Coward · · Score: 0
      <summary-quote>The database spans over 7 languages, 35 topics, and contains common mutations to words that include numbers and capitalization.</summary-quote>

      No, it's not crazy, but the summary indicated that they already had a massive database of hashes->probable_word pairs, and it emphasized that common numeric substitutions on dictionary words could be checked quickly.

      Can you really not see how somebody would be surprised that even the simplest imaginable substitutions (leet-speak for 'hello') are not there?

      People who can't read or think on slashdot, but always have a dumb, passive-aggressive smart ass response. Crazy, ain't it? Sadly, it isn't really crazy or unexpected.

    3. Re:wow by Anonymous Coward · · Score: 0

      Same with 772aac231903404032dedb9c5dcf778e (w1nt3r) which I know I've seen caught by commercial products in the past.

    4. Re:Wow by Mechcozmo · · Score: 1
      This is a great idea!

      (That's the text of the parent by the way)

    5. Re:Wow by Anonymous Coward · · Score: 0

      865c0c0b4ab0e063e5caa3387c1a8741;f0441366488bd123b e0e5fb7d6c03c2b;ea170e2cafb1337755c8b3d5ae4437f4; 0cc175b9c0f1b6a831c399e269772661;5ef76d30bf9232902 687324b5bfa0bd2

      d55669822f1a8cf72ec1911e462a54eb;9e925e9341b490bfd 3b4c4ca3b0c1ef2; 39ab32c5aeb56c9f5ae17f073ce31023;585cae371c4d35318 808a45ce034adab

    6. Re:wow by Thuktun · · Score: 1

      Curiously, both the GP's examples now appear in the database.

    7. Re:wow by eosp · · Score: 1

      when you use the md5sum script on the site, it adds that value.

  12. Linux by sanmarcos · · Score: 1

    My question is, does Linux, more specifically Debian, use MD5 for its passwords? Or what kind of "system" does it use to store and compare hashed passwords?

    1. Re:Linux by arodland · · Score: 2, Informative

      Linux distros these days use MD5 by default -- but they use it in a way that's not so horribly stupid as to be broken by this attack.

    2. Re:Linux by spitefulcrow · · Score: 4, Informative

      Any modern Linux distribution worth its salt (pardon the pun) uses at least an MD5-based salted password storage system. Wikipedia will tell you more about salting. What it boils down to is that using enough bits of salt can make it infeasible for Joe Hacker to store a database of passwords, salts, and their hashed values that would encompass all combinations and allow dictionary attacks against MD5-protected passwords. If your Linux system doesn't use a salted hash to store passwords in /etc/shadow, you may have an issue if untrusted users have access to your system. Then again, if untrusted users have enough access to read /etc/shadow, you have a bigger problem than someone cracking your normal user passwords.

      --
      Sorry, my karma just ran over your dogma.
    3. Re:Linux by isorox · · Score: 4, Interesting

      Linux distros these days use MD5 by default -- but they use it in a way that's not so horribly stupid as to be broken by this attack.

      In an "intro to linux" course I had to take a while back as part of a general engineer course, I noticed that one of the test machines wasn't using /etc/shadow. A few lines of perl, /usr/share/dict and 30 seconds later and I had the root password, the same password as other more important machines. Naturally I mentioned this to the tutors (aftre some subtle brainfucking)

    4. Re:Linux by khrtt · · Score: 4, Interesting

      A friend of mine got his account terminated for a manoeuver like this -- he ran crack over an unshadowed /etc/passwd on one of the machines at his school and sent the output to the sysadmin:-)

      More often then not people are dumb and easily scared. Every time you do something they don't expect you to do, they might treat you as a criminal, no matter what your intentions. If I'd come across someone else's root password, I'd think twice before telling them. That is, unless I wasn't their boss, or hired by their boss to do this.

      BTW, I bet the root password you got was "god", "the plague", or something from the same wavelength:-).

    5. Re:Linux by mdfst13 · · Score: 1

      This also appears in the story about how Intel fired Randall Schwartz, IIRC.

    6. Re:Linux by ValiantSoul · · Score: 1

      One word - Knoppix. I can mount your HD and ignore your fscking file permission system.

    7. Re:Linux by frinkacheese · · Score: 1
      Yeah well, I did that too but I sent the output anonymously to the whole school (whose email addresses were conveniently listed in the GECOS).

      We also had a problem on a RADIUS server recently and we had to dump passwords to a file to fix it. A quick sort -u and guess what the most popular password was? Go on guess..

      Ok I'll tell you, it was "password"
      ....

    8. Re:Linux by isorox · · Score: 2, Interesting

      princess

    9. Re:Linux by Anonymous Coward · · Score: 0

      wtf has physical access got to do with the thread or the article or anything? dumbass.

    10. Re:Linux by rhizome · · Score: 4, Insightful

      More often then not people are dumb and easily scared. Every time you do something they don't expect you to do, they might treat you as a criminal, no matter what your intentions.

      This is why it's not a good idea to humiliate people who have more power than you if you have something to lose.

      --
      When I was a kid, we only had one Darth.
    11. Re:Linux by Anonymous Coward · · Score: 0

      Every time you do something they don't expect you to do, they might treat you as a criminal, no matter what your intentions.

      Like the guy who accessed an Olympic (oops, not allowed to say that word am I?) related web site with Lynx and then found cops at his door for his "hacking".

    12. Re:Linux by rcbarnes · · Score: 1

      Actually, according to a study a few years ago, "password" is by far the most common password in use today. Your observation is perfectly in line with that...

      Sad, eh?

      --
      "Fight for lost causes. You may discover they weren't."
    13. Re:Linux by Anonymous Coward · · Score: 0

      Learn something about how Linux stores password hashes, genius.

    14. Re:Linux by indifferent+children · · Score: 3, Insightful

      Booting the machine in Knoppix requires that the 'bad guy' have physical access to the machine. Even if physical access cannot be well restricted, you can turn-off 'boot from CDROM' in the bios, and password-protect the bios. Now the 'bad guy' has to open the machine, find the motherboard-type, find out which jumper clears the bios password(s), etc. Most machines can also be padlocked shut, so now the 'bad guy' needs to bring a Dremel or such.

      --
      Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
    15. Re:Linux by Alarion · · Score: 1

      A more appropriate course of action, in the interest of CYA would have been to first inform the sysadmin that the method which passwords are stored on the system is insecure and the root password could be obtained in a matter of hours/minutes/seconds.

      At this point, you have done nothing wrong, and he might just ask you to "prove it". At this point, you have been (to a point) authorized by the sysadmin to do what you did.

      Not such a big deal at school I suppose, but had you lost your account at work, or been fired over it...

    16. Re:Linux by Anonymous Coward · · Score: 0

      idiot. the post said "Then again, if untrusted users have enough access to read /etc/shadow, you have a bigger problem than someone cracking your normal user passwords."

      how is physical access even relevant here? if you have it, you don't need to crack passwords. if you don't have it, you still can't crack them with the method in the article because of salt.

      fucking moron.

    17. Re:Linux by AHumbleOpinion · · Score: 1

      This also appears in the story about how Intel fired Randall Schwartz, IIRC.

      Actually you dont remember correctly. He was not an employee, he was not responsible for the machines he was doing this sort of thing on, he was also doing things like punching holes in theif firewall after being told not to do so. Now Intel and local authorities were quite overzealous in his prosecution, but he was also victim to his own stupidity. If you are a contractor and you want to test security make sure the sysadmin for the machine knows. FBI stats show that most computer crime is comitted by insiders, not the outside hacker boogyman of TV and movies. It is reasonable for the company to suspect that you are up to no good.

    18. Re:Linux by hackstraw · · Score: 1

      Any modern Linux distribution worth its salt (pardon the pun) uses at least an MD5-based salted password storage system.

      And doesn't that modern Linux distribution conveniently store those salt entries as the 8 characters following the $1$ characters in the /etc/shadow file (or more conveniently in /etc/passwd)?

    19. Re:Linux by Anonymous Coward · · Score: 0

      BTW, I bet the root password you got was "god", "the plague", or something from the same wavelength:-).

      He should not tell you, the guy probably hasn't changed his password yet.

    20. Re:Linux by evilviper · · Score: 1

      Clearing a CMOS password is as simple as plugging-in a keyboard.

      Yeah, you have to make the device before-hand, and you need to carry it around with your boot-CD, but it's really not very difficult.

      Padlocks are good mainly to keep the casual thief from removing the case panel and going home with your high-end graphics card, RAM, HDD, CPU, etc. Add a cable to keep someone from walking away with the whole tower.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    21. Re:Linux by Geoffreyerffoeg · · Score: 1

      This is why it's not a good idea to humiliate people who have more power than you if you have something to lose.

      The what? Just say "Hey, the computer system has a bug that doesn't properly encrypt the passwords. They're even visible to anyone who looks."

      Don't put the blame on them, because truly it's the system's fault for not salting the passwords.

    22. Re:Linux by Anonymous Coward · · Score: 0

      Old debian installers asked whether or not you wanted to use MD5 and whether or not you wanted to use shadow passwords. By "old" I mean around version 2.2 (ie ~8 years old or so). So for those systems the answer is "it depends" on what you chose. I don't know if the newer installer gives the option, but I suspect that it doesn't. It probably just uses MD5 and shadow passwords. HTH.

    23. Re:Linux by rhizome · · Score: 1

      Don't put the blame on them, because truly it's the system's fault for not salting the passwords.

      Oh, I'm not assigning blame. While the IT department should certainly account for their incompetence, that the administration lashes out rather than admit to a problem really comes as no surprise.

      --
      When I was a kid, we only had one Darth.
  13. MD5 is nice but... by nmb3000 · · Score: 5, Informative

    What would be really nice is to see this grow past a simple MD5 database. If you're going to get traffic, you really should get an NTLM database up and start populating it as soon as possible.

    A few other places have these, in differing amounts. Rainbowcrack has tons of them, but require you to submit some before being allowed to query the system. I did submit a few NTLM hash tables, but it took the better part of a week to get my query back (it's supposed to be a lot faster than that).

    There's also Ophcrack which uses tables similar to rainbow tables. It has a web interface to query NTLM hashes for simple passwords.

    With these pre-computed hash tables, basic password security is starting to take a hit and it's becoming more and more worthwhile to use a simple but long password rather than a short and complex one. If you're on Windows, it's also VERY worthwhile to read about forcing Windows to store only the NTLM hash and drop the LM hash. It breaks old compatibility with Win 9x but is very worth it if you don't need that. This helps against precomputed attackes but has an even bigger impact agains brute-force attacks.

    --
    "What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
    /)
    1. Re:MD5 is nice but... by aicrules · · Score: 3, Insightful

      GREAT! So now all freaking IT security departments are going to up the minimum password length to like 64 in ADDITION to having to change it every other day, not being able to use the last 1000 passwords you've ever used, and requiring alternating caps, numbers, and punctuation.

      Sure, I'm exaggerating a little, but the amount of time I have to spend on password maintenance is nearly making a line item on my time sheet.

    2. Re:MD5 is nice but... by Nailer · · Score: 2, Interesting

      it's also VERY worthwhile to read about forcing Windows to store only the NTLM hash and drop the LM hash.

      I thought NTLMv2 was MD4, which is still broken according to its inventors?

    3. Re:MD5 is nice but... by Ossifer · · Score: 1

      When I run into this I usually the the IT head about how great his security standards are--so great that I need to write down each password on a post-it note... Now that's security!

    4. Re:MD5 is nice but... by fbjon · · Score: 1

      Actually, the smartest would be to require diceware passwords with a few simple permutations.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    5. Re:MD5 is nice but... by xsbellx · · Score: 1

      It already is a line item, 2.5 days every month.

      Approximately 600 systems split between Solaris and AIX, three change management systems (actually 1200 because root gets changed monthly), two VPN solutions and at last count about a dozen different pasword standards.

      Kind of sucks the will to live right out of you!

      --
      If VISTA is the answer, you didn't understand the question
    6. Re:MD5 is nice but... by Anonymous Coward · · Score: 0

      If you're on Windows, it's also VERY worthwhile to read about forcing Windows to store only the NTLM hash and drop the LM hash [microsoft.com]. It breaks old compatibility with Win 9x but is very worth it if you don't need that.

      Does Samba still rely upon having the LM hashes? That's what kept me back a few years ago.

  14. Bug in counter by SirPrize · · Score: 1

    I think there's some kind of bug in the counter, or the site is being ./'d, with over 65535 or 2^64-1 hits, as I initially saw the counter with a value of around 70, and now when I look at it, the counter had gone DOWN to 30 something, and was on the increase again.

    1. Re:Bug in counter by Randseed · · Score: 1

      Simple. The 31337 h4xx0r5 are all dumping their databases into it, trying to see if they can find any gold, as it were.

  15. Pointless. by Randseed · · Score: 2, Insightful
    I generated a PHP script that does password managing a couple of weeks ago, and even I used a SALT in the process. I suppose that this is useful if you come across a site so horribly broken as to not use a SALT, or if you know the SALT ahead of time somehow. (Not hard to do the latter, really.)

    All in all, this is another ho-hum kind of story.

    1. Re:Pointless. by gardyloo · · Score: 3, Funny

      I suppose that this is useful if you come across a site so horribly broken as to not use a SALT [...]

          In that case, you might try battery...

  16. What's With The...Bragging by Anonymous Coward · · Score: 0

    Page generated in 0.000568 seconds.

    The dude knew the slashdot crowd was heading his way so he put in a timer just to look impressive... sigh.

  17. Advantages by Elitist_Phoenix · · Score: 5, Funny

    What advantages does this database have over say a Cray supercomputer, which I could also afford.

    --
    "I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
  18. md5summer.exe by weighn · · Score: 0

    if anyone is interested, the md5 hash for the md5 summer (win32) is 6f122df5e2b86bc0bc8885cafe4b9eab

    --
    Mongrel News all the news that fits and froths
    1. Re:md5summer.exe by Anonymous Coward · · Score: 0
      if anyone is interested

      No.

    2. Re:md5summer.exe by Flaming+Foobar · · Score: 1
      >> if anyone is interested
      > No.

      I guess you didn't get his joke, then.

      --
      while true;do echo -e -n "\033[s\n\033[u\134_\033[B";done
  19. Crypto experts... SHA1? by mnemonic_ · · Score: 1

    Would these (or similar) attacks work against sha1 hashes?

    1. Re:Crypto experts... SHA1? by Anonymous Coward · · Score: 3, Informative

      It is not an attack, it is just a dictionary.
      It works for any hash function.

    2. Re:Crypto experts... SHA1? by chialea · · Score: 3, Informative

      They're just precomputing hashes, from what I can see. There's nothing that stops you from doing it for a very large number of inputs and storing the results. If you want to get a collision using that precomputation, however, it'll be a lot harder on SHA-1 than on MD-5, even given the new attacks on it. (If you're curious about the attacks, look at this years' CRYPTO papers. Professor Wong and her team have come out with some great stuff.) Preimage attacks will probably still be difficult on SHA-1, as the new results don't signifigantly impact the property of preimage-resistance (from what I saw of the attacks in the talks).

      The upshot is: (1) yes, you can do this, it's just brute-force; (2) it's not as easy with MD-5.

      Lea

    3. Re:Crypto experts... SHA1? by cbrocious · · Score: 1

      So long as the hashes aren't salted, which they most likely aren't in many cases, although they should be.

      --
      Disconnect and self-destruct, one bullet at a time.
    4. Re:Crypto experts... SHA1? by springbox · · Score: 1

      Yeah, but who's using SHA-1 to hash their passwords? MD5 is certainly the most common hashing function for this.

  20. For those that don't know by Sycraft-fu · · Score: 5, Informative

    To call LM weak would be an understatement. LM takes passwords up to 14 charackets in length, fine you think until you realise that the way tey did it is to hash 2 7-character strings. This means for any password, you have to crack a max of 7 characters. Oh, and did I meantion it's case insensitive?

    There are existing ranbowtables covering basically the entire LM space but, really, you don't need it. A fast dual core chip will crack it in less than a day.

    The parent is correct in that in all cases you can you should set Windows to only use NTLM, or better yet NTLMv2. We are (finally) getting to do that at work as we purged the last NT and 98 systems from the domain.

  21. Take it from me... by Saeed+al-Sahaf · · Score: 3, Funny
    What advantages does this database have over say a Cray supercomputer, which I could also afford.

    Does not take up as much room, and someone else is responsible for the maintenance. It's too late for me, but you might benefit from my shortsightedness.

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    1. Re:Take it from me... by Elitist_Phoenix · · Score: 1

      Gotcha, Warehouse and baseball bat it is then!

      --
      "I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
  22. MOD PARENT INFORMATIVE by Anonymous Coward · · Score: 0

    This is not about a weak hash, the dictionary is only a threat to wrong use of the hash.

  23. Wow by elronxenu · · Score: 0, Offtopic

    9e925e9341b490bfd3b4c4ca3b0c1ef2; a2a551a6458a8de22446cc76d639a9e9; 0cc175b9c0f1b6a831c399e269772661; acaa16770db76c1ffb9cee51c3cabfcf; 1cba77c39b4d0a81024a7aada3655a28.

  24. Compression Algorithm by PingPongBoy · · Score: 2, Funny

    With this database suddenly all files are compressible to 32 bytes. A 1440 Kb floppy disk can store 46080 MD5 hashes. If each hash represents a file that is on average 10 Mb, the floppy disk can store 461 Gb on average.

    This is quite useful for archival purposes.

    The whole idea of information versus random noise is really apparent when you compare which MD5 hashes have personal significance to the set of all possible hashes.

    --
    Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
    1. Re:Compression Algorithm by Anonymous Coward · · Score: 3, Informative

      MD5 hashes aren't unique. There are around 2^105 (around 10^32, or 10 decillion) 10 MB files with the hash '498b4ddc9f957eca6473923163dd117f', for example. There's also a five-letter word that coincidentally hashes to that value AND describes you, but you can find it yourself.

    2. Re:Compression Algorithm by chatgris · · Score: 0

      "A 1440 Kb floppy disk can store 46080 MD5 hashes"

      Unless you did raw device io, FAT12 (which is the standard floppy format) has overhead associated with its fat table... You won't fit that many :)

      --
      Open Your Mind. Open Your Source.
    3. Re:Compression Algorithm by Anonymous Coward · · Score: 0

      "With this database suddenly all files are compressible to 32 bytes"

      *sigh*

      There were idiotic messages like this all the the time to comp.compression, and they were always swatted down. But here, in the "News for Nerds", this gets modded to +5 Interesting!

      An easy test: Why a lossless compression algorithem that compresses all possible files doesn't exist? (Hint: count all possible files expressed by a certain number of bits)

    4. Re:Compression Algorithm by Anonymous Coward · · Score: 0

      MD5 hashes are only 16 bytes in size (128 bits).

    5. Re:Compression Algorithm by Anonymous Coward · · Score: 3, Interesting

      It's kind of strange how the moderation of a post can change its meaning. I was reading the parent post when it was modded "+5 interesting". I thought it was a crock, as everyone knows that since hashes have collisions, they cannot be used for lossless (or practical lossy) compression.

      Anyway, I pressed Reload to see if there were any new posts, and stumbled upon the parent again, now moderated "+5 funny". My first thoughts were "what a subtle parody....wait a minute, this looks familiar".

    6. Re:Compression Algorithm by Anonymous Coward · · Score: 0

      The whole idea of information versus random noise is really apparent when you compare which MD5 hashes have personal significance to the set of all possible hashes.

      Think about it for a minute and you'll realise that this doesn't make any sense. There are 2^128 possible hashes. This is _vastly_ outnumbered by the total number of possible files, even if you restrict yourself to files that are not random noise.

    7. Re:Compression Algorithm by mlush · · Score: 4, Funny
      With this database suddenly all files are compressible to 32 bytes. A 1440 Kb floppy disk can store 46080 MD5 hashes. If each hash represents a file that is on average 10 Mb, the floppy disk can store 461 Gb on average.

      Your missing a trick.. you could reduce the file of MD5 hashes with MD5, write it down and carry 461 Gb on a postit note!

    8. Re:Compression Algorithm by Ann+Elk · · Score: 1

      Yes, and like many other archiving solutions, backup works great but restore is "problematic"...

    9. Re:Compression Algorithm by indifferent+children · · Score: 1

      It's a WORN backup system: Write Once, Read Never

      --
      Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
    10. Re:Compression Algorithm by Just+Some+Guy · · Score: 1

      Bad time to find out that the changeset you just sent, compressed, to your boss has the same hash as goatse.cx.

      --
      Dewey, what part of this looks like authorities should be involved?
    11. Re:Compression Algorithm by WilliamSChips · · Score: 0

      What is the Counting argument for $400, Mr. Trebek?

      --
      Please, for the good of Humanity, vote Obama.
    12. Re:Compression Algorithm by jkirby · · Score: 1

      This is called compare-by-hash. There is a great paper by Val Hensen http://infohost.nmt.edu/~val/review/hash.html on the subject

      --
      Jamey Kirby
    13. Re:Compression Algorithm by Anonymous Coward · · Score: 0

      I'd think twice before calling people with 5-letter words if I didn't know the difference between 2^105 and 2^79999772.

    14. Re:Compression Algorithm by Paul+Crowley · · Score: 1

      I make that 2^83885952 (10*1024*1024*8-128) but relative to the error you're pointing out, you're roughly correct.

  25. You might expect that... by Beryllium+Sphere(tm) · · Score: 2, Interesting

    >You all use salted md5 hashing in your applications, don't you?

    I was just reviewing some popular browser extensions that create site-specific passwords. Click a widget, enter a keysequence or something like that and they fill in a password that's an MD5 hash of the site name concatenated with a master password from the user.

    No salt.

    There are probably blackhats out there who have *memorized* the MD5 of "passwordpaypal.com".

    1. Re:You might expect that... by jessecurry · · Score: 0

      in this case wouldn't the master password from the user serve as the salt?

      --
      Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
    2. Re:You might expect that... by GryMor · · Score: 1

      Not really, as it means Black Hat Site A can work out your master password and then use it on other sites.

      Salt needs to be large, random and generally kept local to the machine doing the authentication (in this case, the machine doing the authentication is the users password repository). Each generated password needs it's own salt.

      --
      Realities just a bunch of bits.
    3. Re:You might expect that... by baadger · · Score: 4, Informative

      This is lightly salted.

      "slashdot.org<my password>" will render any generic databases like GData useless for Slashdot password searching. It means someone has to build up a Slashdot specific database using a dictionary first. That is all a salt is really for, to inconvenience a dictionary attack.

      "slashdot.orgbaadger<my password>" (<site><username><password>) would be better as it means the cracker has to build a database specific to slashdot and my username.

      So yes these passwords are salted, using the domain just saves the plugin having to save random salts somewhere.

    4. Re:You might expect that... by baadger · · Score: 1

      Furthermore salts do not have to be large, random or kept local, as you said in sister post. Provided the cracker has to generate a new hash dictionary it has acheived it's task and this means if you're salt doesn't make your plaintext another plaintext thats found in the crackers database, it has acheived it's goal.

      Secret, long and random salts known to both sides and never transmitted will produce a MAC.

    5. Re:You might expect that... by irc.goatse.cx+troll · · Score: 2, Interesting

      They arn't trying to find your password, just find something that has the same MD5. If kf9fqufccqhtqrthcferhwughw has the same hash as slashdot.orgbaadgerlolhy, I can login with either and slashdot wont care. Granted, it will stop a dictonary attack, but your password shouldnt be that weak anyways.

      --
      Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
    6. Re:You might expect that... by baadger · · Score: 1

      But you missed the point that we are assuming the cracker knows H(slashdot.orgbaadgerpassword) not H(password). If slashcode adds the "slashdot.orgbaadger" prefix before applying the hash for matching then the generic dictionary attack is useless.

    7. Re:You might expect that... by Anonymous Coward · · Score: 0

      The password generator bookmarklet

      It's javascript which asks for your "master password" (i.e. just use one for everything), then calculates MD5(password + site name), and places that into any password input boxes on the page you're currently viewing.

    8. Re:You might expect that... by Lord+Ender · · Score: 1

      I don't think you realize just how big 128 bits is...

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    9. Re:You might expect that... by m50d · · Score: 1

      True salting adds more than that because the attacker has to capture the salt (which with shadow passwords means you need root access) before they can even start building the database.

      --
      I am trolling
    10. Re:You might expect that... by dasunt · · Score: 1
      They arn't trying to find your password, just find something that has the same MD5. If kf9fqufccqhtqrthcferhwughw has the same hash as slashdot.orgbaadgerlolhy, I can login with either and slashdot wont care. Granted, it will stop a dictonary attack, but your password shouldnt be that weak anyways.

      If the client is sending the hash to the server, then yes, "kf9fqufccqhtqrthcferhwughw" works just as well as "slashdot.orgbaadgerlolhy". But if the client only sends the password "lolhy" to the server, and the server builds the hash by prepending "slashdot.org", then the MD5-encrypted list of passwords is useless to compare against a MD5 password database, since "slashdot.orgbaadgerkf9fqufccqhtqrthcferhwughw" won't have the same hash as "slashdot.orgbaadgerlolhy".

  26. Windows shouldn't send either NTLM or NTLMv2 by Nailer · · Score: 1

    http://www.google.com/url?sa=t&ct=res&cd=2&url=htt p%3A//www.blackhat.com/presentations/bh-asia-04/bh -jp-04-pdfs/bh-jp-04-seki.pdf&ei=iXUJQ4yLOK2UsAGU9 PzUDQ

    Yeah, NTLMv2 is MD4, which is broken, doesn't allow salting, and doesn't even need to be cracked anymore, just looked up in a Rainbow table.

    My question for Windows admins: can I use kerberos for everything in Windows, so it never sends a hash, never ever, ever, across the network? Just TGTs and service tickets encrypted with that hash?

    That's network logins, access to shares, and any other time a password may travel across the network.

    1. Re:Windows shouldn't send either NTLM or NTLMv2 by Anonymous Coward · · Score: 0

      Kerberos isn't much better because it still stores a shared password on the server. While it avoids sending the password or a reversable hash over the network, it does have to store the password on the server in plain text, or an easily reversable encryption.

      I'm still waiting for a good system that uses x.509 digital certificates. You generate your own public/private keypair and nobody but you ever needs to know the private key. This could be done on a smart card and the prviate key will never leave the smart card. You just send the rest of the certificate to your certification authority to verify, sign, and return to you, and you're set.

      Then to log in you need to have your certificate either on the machine, or on some removable media you plug in, AND enter your password that is used to 3des encrypt your private key. Then your private key is used to sign authentication requests from the rest of the machines on the network.

      It's also faster and more reliable than kerberos because when your machine wants to authenticate with another server on the network, under kerberos your machine must speak with a domain controller to get a service ticket for the target machine. With certificates, your machine simply uses your private key to sign a challenge token from the target server, which it then can validate against your public key in your certificate. The server can validate the certificate itself against the public key of the certificate authority, which it must know a priori, but it doesn't have to know anything about YOUR certificate before you try to speak with it.

  27. Salting *and iterating* by Paul+Crowley · · Score: 5, Interesting

    Actually I have seen many applications that fail to salt passwords before hashing them; it's depressing. Salt should be long enough to be globally unique when randomly generated. Old-style Unix passwords used a 12-bit salt, which was pathetic; 128 bits would be plenty.

    In addition, it's best to iterate the hash many times, which slows down dictionary attacks. See Kelsey, Schneier et al, "Secure Applications of Low-Entropy Keys":

    http://www.schneier.com/paper-low-entropy.html

    The proofs in that paper are based on the assumption that the hash function is collision free, which of course MD5 isn't; another hash function might be preferable.

    1. Re:Salting *and iterating* by Anonymous Coward · · Score: 1, Funny

      The proofs in that paper are based on the assumption that the hash function is collision free, which of course MD5 isn't; another hash function might be preferable.
      Yeah, I use such a hash function together with a neet compression algo, that compresses any byte sequence to a single bit. It just hard to control the quantum bit hyper flux compensation. But then everything is nice.

    2. Re:Salting *and iterating* by Anonymous Coward · · Score: 0

      The problem with straightforward iteration is that it's okay to do it 25 times (adding a pathetic ~5 bits of security) but not say, 65536 times since it greatly increases the likelyhood of entering a loop which together cover only a subset of possible hashes.

    3. Re:Salting *and iterating* by fbjon · · Score: 1

      What kind of hash function would be collision free, if the input is arbitrary in length?

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    4. Re:Salting *and iterating* by fbjon · · Score: 1
      One of my friends made a file compression algorithm that compressed any file to zero bytes. It simply deleted the file, thus freeing up the disk space.

      When you wanted to uncompress, it undeleted the file. Lossless compression, mostly!

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    5. Re:Salting *and iterating* by EndlessNameless · · Score: 1

      A hash function will, by definition, have collisions. Good hash functions have fewer collisions and make it extremely difficult to compute collisions from a known hash value (and therefore prevent an attacker from creating an arbitrary false message with the same hash as an original message).

      All modern hash algorithms succeed at the last criteria; the first, criteria, however is much more difficult to assess fully, and it is therefore one of the things that is found out over time as the algorithm is tested.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    6. Re:Salting *and iterating* by fbjon · · Score: 1
      That's the problem. How do I know that the hash for my 15-word diceware password doesn't collide with the hash for 'qwerty'? I can compute it myself of course, but only if I know which hash function, which I generally don't know on systems I don't manage myself.

      In other words, should a good password always be checked against all known hash dictionaries, before it can really be considered a secure password? I can imagine it being a pretty good idea for a system that wants to avoid dictionary attacks, doing a routine hash-checkup for every user that changes his password.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    7. Re:Salting *and iterating* by Paul+Crowley · · Score: 1

      Obviously collisions exist, as a simple counting argument proves. "Collision free" is a technical term denoting that finding collisions in that hash function is hard.

    8. Re:Salting *and iterating* by Paul+Crowley · · Score: 1

      No. If your password is not in the hash database, and the password system is half decent (eg MD5 + salt), the probability of your password colliding with any of the passwords in the hash database above is so negligibly small that there is no point in checking for it.

  28. Trojan alert by Anonymous Coward · · Score: 5, Informative

    Visiting this site (md5 one) resulted in pop-ups which were loaded with the StartPage Trojan which fortunately F-Secure spotted.

    1. Re:Trojan alert by Anonymous Coward · · Score: 1, Informative

      I just spent the last hour removing one of the trojans. For anyone else that gets caught out here's the instructions to remove it. http://www.androidworld.com/prod91.htm

    2. Re:Trojan alert by spagetti_code · · Score: 1

      Didn't happen with firefox :-)

    3. Re:Trojan alert by Anonymous Coward · · Score: 0

      Same here with eTrust.

    4. Re:Trojan alert by jafuser · · Score: 1

      Firefox + NoScript + FlashBlock + AdBlock

      It may sound at first like this would make the web unusable, but it's not really all that bad. It takes two clicks to add a domain to NoScript's whitelist and one click to re-enable a Flash. AdBlock is good for removing the most offensively annoying ads with two clicks.

      --
      Please consider making an automatic monthly recurring donation to the EFF
    5. Re:Trojan alert by hackstraw · · Score: 1

      Visiting this site (md5 one) resulted in pop-ups

      What are popups?

      I remember some obnoxious sites like CNN and other sites that used to open unannounced windows like 4 or 5 years ago, but I thought nobody used them anymore. /me scratches head, and remembers the "bad times"

    6. Re:Trojan alert by Anonymous Coward · · Score: 0

      Trojan [dikweedia] - one of the many extras provided free of charge to an IE user.

      IE User [dikweedia] - someone who leaves the front door open while on vacation, comes home, and wonders while he was robbed.

  29. e1568c571e684e0fb1724da85d215dc0 by ShakiirNvar · · Score: 2, Interesting

    but as previously pointed out, with a few minor additions (as to which it depends on whether you prefer salt or pepper :p) to the procedure, this database becomes a minor security concern.

    --
    "Nobody ever went broke underestimating the intelligence of the American public." - HL Mencken
  30. Security to obscurity by drange_net · · Score: 1

    This seems to a good reason to do some obscure MD5-security hacks like nested MD5 hashing or reversing string before hashing it...

  31. Quick MD5 Generation page by trevdak · · Score: 1

    I threw this together in all of 5 seconds. http://www.cif.rochester.edu/~trevdak/md5.php

    1. Re:Quick MD5 Generation page by tendays · · Score: 1

      heh, clever, now people will be posting their passwords to your website :-)

    2. Re:Quick MD5 Generation page by Anonymous Coward · · Score: 0

      Or you can open an xterm and type "md5" or "md5sum" like everyone else. :-)

      PS: also a Rochester student here.

  32. md5 hash is that like a new leet speak ? by bxbaser · · Score: 1

    eom errr i mean
    9fe9245f628fd735e094285801ef2c36

  33. Interestingly... by hajejan · · Score: 3, Interesting

    Interestingly, do a MD5 hash of 1

    The result is c4ca4238a0b923820dcc509a6f75849b

    Do a google search for that string.

    That results in roughly 2000 hits. That's 2000 people running un-salted hashes...

    --
    The Mini Repository - more links
    1. Re:Interestingly... by Antony.S · · Score: 2, Interesting

      or 2000 collisions...

    2. Re:Interestingly... by stray · · Score: 5, Interesting

      Hm, why did I never try this before :-) ?

      echo -n "trustno1" | md5sum
      5fcfd41e547a12215b173ff47fdd3739

      Google for it, nice vector there.
      Disturbing, to say the least.

    3. Re:Interestingly... by stray · · Score: 1, Funny

      but please be nice with that furlong47 guy and don't mess with his account!

    4. Re:Interestingly... by fbjon · · Score: 1
      And don't do anything with these unsalted hashes from a database dump courtesy of Google cache.

      Ok, so I tried some, but it didn't work. Too old dump I guess.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    5. Re:Interestingly... by caluml · · Score: 1

      I bet 'scarlet_harlot@hotmail.com' gets a few IMs/emails though.

    6. Re:Interestingly... by pclminion · · Score: 1
      Interestingly, do a MD5 hash of 1
      The result is c4ca4238a0b923820dcc509a6f75849b

      Also, try the MD5 of the MD5:

      echo -n c4ca4238a0b923820dcc509a6f75849b | md5sum
      28c8edde3d61a0411511d3b1866f0636 -

      That also turns up hits.

  34. NO-O-o-o!o!o! by Anonymous Coward · · Score: 0

    You DID NOT type your live passwords into that did you?

  35. crack it and print it publicly in the hall way by cheekyboy · · Score: 3, Funny

    THe best way to 'shame' the admins publicly, is to crack it on your pc or laptop at home, print out the passwords, and then covertly, where there are no cameras, or if its REAL REAL busy with your sly quick hand, pin the passwords to the main notice board, then watch 50 other idiots use it to really screw up the system.

    The school would be real real dumb to expell or terminate 50 students accounts.

    Or if your really brave, get some weed killer and write the password on the front lawn, and watch it magically appear over the weekend. Totally funny and covert. Admins would get the sack and they would be a school legend.

    Usual passwords are either startrek or hitch hickers guide related.

    --
    Liberty freedom are no1, not dicks in suits.
  36. OT:Compression Algorithm by EnigmaticSource · · Score: 1

    *Laughs Dew From Nostrils*
    Oh, if you weren't an AC I'd hug you.

    --
    The Geek in Black
    I know my BCD's (when I'm Sober)
  37. reverse-password generation? by MadCow42 · · Score: 1, Funny

    Personally, I'd love to use a password with an MD5 hash that came out something like "FyoMamaSysAdmin"... any tools for generating THAT? :)

    MadCow.

    --
    I used to have a sig, but I set it free and it never came back.
    1. Re:reverse-password generation? by dhasenan · · Score: 1

      MD5sums are expressed in base-17. You get values from 0 to 9 and from a to f. So if you l33t it carefully and only use letters a-f, sure.

    2. Re:reverse-password generation? by CoderBob · · Score: 1

      You mean base-16, right? As in, hexadecimal, which runs from 0-F? Or are you implying that through careful password choosing, you can get the letter G in there and you meant it runs from 0-9 and a-g?

    3. Re:reverse-password generation? by CoderBob · · Score: 1

      Dammit, if this double posts, I'm sorry, but the first one isn't showing up still.

      You mean base-16, right? You weren't going to try and sound like a nerd on a site full of admins and programmers by thinking that 0-9 (10 digits) plus a-f (6 digits) somehow turns into a base-17 system?

    4. Re:reverse-password generation? by Anonymous Coward · · Score: 0

      ITS BASE 16. You should be shot for your post. You should also be banned from using 133t.

    5. Re:reverse-password generation? by jolyonr · · Score: 1

      That's Base 16 on my planet.

      --


      Please read my Canon EOS tech blog at http://www.everyothershot.com
    6. Re:reverse-password generation? by Knackered · · Score: 1

      Base 16. Base-17 would include 'g'.

      --
      a.
    7. Re:reverse-password generation? by Govno · · Score: 1

      I could be wrong, but isn't 0~9 + a~f base-16 aka hexadecimal?

  38. Lame by cryptoguy · · Score: 1

    They have "password" but not "PASSWORD". Much less, "pAssWOrD" or "p455w0rd" or "0qww294e" (transposed up one row on querty keyboard).

    John the Ripper need not fear.

    1. Re:Lame by Chosen+Reject · · Score: 2
      transposed up one row on querty keyboard).

      At first I thought that maybe 'querty' was a new layout for keyboards. So I did a google search on it and found nothing. Then I just realized that spelling has gotten so bad that people can't even type letters in a row. It's QWERTY. It's named for the layout of the letters on the keyboard such that the Q, the W, the E, the R, the T and the Y are in a row. For crying out the freaking loud, you sir, fail it big time.

      --
      Stop Global Warming!
      Just say no to irreversible processes!
    2. Re:Lame by Anonymous Coward · · Score: 0

      oops. Looks like a bug in the Slashdot spell checker ;->

  39. Pi is better. by Fantastic+Lad · · Score: 2, Interesting
    An infinite, non-repeating number must contain ALL possible data, right?

    --Including next week's winning lottery numbers, a picture of your face, blue prints to your house, your brain, and a nice little faster-than-light getaway vehicle and the formula for its shocking-pink meteorite-resistant paint.

    It's just a matter of finding the right sequences. Or building a device which can find those sequences for you upon request. --I call such a device an, "Infinity Box".


    -FL

  40. True password story... by Anonymous Coward · · Score: 0
    This one is true - I was there. A few years back I was working for a public sector organization and my boss at the time told one of my coworkers to change the system admin password - which he did.

    Well... at lunch time in the cafeteria while my boss was eating a big bowl of clam chowder casually asked what the new password was changed to, just as he was about to take a spoonful.

    My boss almost lost his cookies when he heard what it was. It was changed to phlegm

  41. Failure by AndyFewt · · Score: 1

    Well, I tested it with 2 letters and 2 numbers. I got the hash from a very quick php script I had from years ago. Then when I ran the hash through the site it said the pass is "?????" -- Failed. -- I even got the same hash for the letter/number combo through their site just in case it logs the generated hashes for later. Still failed.

    Also that "Total number of cracked hashes" is looking like a random number as it was at 128, then 50, then 1. I know there are some logical answers to it, but all of them, well, silly mistakes.

    1. Re:Failure by PlusFiveTroll · · Score: 1

      Also that counter is being weird jumping from like 128 to 1 then to 50.

      That could be a database table error, like they used a signed tinyint to store the number. Once it hits 128 it wraps back to 0.

    2. Re:Failure by AndyFewt · · Score: 1

      Yeh I did mention that in an original post but I forgot to hit submit (just preview). There are a number of possible reasons, but all show lack of planning ;)

  42. Failure by AndyFewt · · Score: 1

    I tried multiple words with simple number replacement for letters like o. The bit of blurb seems to imply this would work but as I've found out it doesnt. The word of choice? "monday".. It did have the "monday" hash in the database so you would think it would have some with numbers as the text says. So lets try "m0nday"... FAILED... Also that counter is being weird jumping from like 128 to 1 then to 50.

  43. WARNING THIS IS A STUPID QUESTION by cortana · · Score: 1

    The crypt() function takes two arguments: a key and some salt characters. But the MD5/SHA1 functions I have seen only take one argument. So how do you salt an MD5/SHA1 hash? Is it enough to do md5 (username . password)?

    1. Re:WARNING THIS IS A STUPID QUESTION by mg2 · · Score: 1

      Unfortunately, the md5 function won't usually take a salt argument. You can salt it easily by hand, though, by doing something along these lines:

      function saltedMD5($plaintext)
      {
          $salt = randomString(8);
          $ciphertext = md5($plaintext);

          $saltycipher = '$1$' . $salt . '$' . $ciphertext;

          return $saltycipher;
      }

      (note: consider this pseudocode, as it's some kind of cross between PHP and Perl)

      This function accepts a password and returns one like this:

      $1$rjWol9cE$MRr13YqfuhasxTkyIjUiY1

      This is the standard format for shadowed passwords for most modern *nix distributions, and it's invulnerable to lookups in most general-purpose databases.

    2. Re:WARNING THIS IS A STUPID QUESTION by Tesser · · Score: 1

      Consider me stupid, but why isn't this as follows instead?

      function saltedMD5($plaintext)
      {
              $salt = randomString(8);
              $ciphertext = md5($salt . $plaintext);

              $saltycipher = '$1$' . $salt . '$' . $ciphertext;

              return $saltycipher;
      }

      In other words, in your example, why isn't the calculated salt actually used in the MD5?

      Seems like all the original pseudocode did was prepend some random chars in front of the hash which had no effect on the cypher?

    3. Re:WARNING THIS IS A STUPID QUESTION by mg2 · · Score: 1
      If you look closely at the function, first the variable $salt is generated randomly. Second, an an md5 hash is generated for "$salt . $plaintext" which in Perl and PHP equates to contatenating the salt with the plaintext, thereby incorporating the salt into the hash.

      The salt is prepended to the cipher only so that it can be used during decoding. That is, the decoding function will grab the salt from between the second two dollar signs and prepend it to the cleartext string that it's hashing.

    4. Re:WARNING THIS IS A STUPID QUESTION by Tesser · · Score: 1

      It is in my corrected code, yes. Not in the original post-- which was precisely my point. ;-)

    5. Re:WARNING THIS IS A STUPID QUESTION by mg2 · · Score: 1

      Oops =P

  44. key/location pairs by sgt+scrub · · Score: 1

    I don't have a web site for this so just e-mail me an outline of your car key, the cars location, its make, its model, and plate number. Thank you for your co-operation.

    --
    Having to work for a living is the root of all evil.
    1. Re:key/location pairs by Anonymous Coward · · Score: 0

      Yeah Seriously, lets all go to myNotReputableSite.com and give out ip addresses and hashed pwd's stored by your OS to someone you don't know... :P

  45. Speed The Fall of md5 by ObsessiveMathsFreak · · Score: 1

    Do your bit for the destruction of md5 by adding to the database using this simple script!

    #! /usr/bin/perl
    system 'apg -n 5 > okpasswords';
    open(passfile, "okpasswords");

    while($password = ){
            chop $password;
            print $password.";";
    }
    print "\n";

    Then just paste 'em in.

    Farewell Md5. Thou hast served us surprisingly well.

    --
    May the Maths Be with you!
    1. Re:Speed The Fall of md5 by Anonymous Coward · · Score: 0

      And if they use a salt?

      This is just one of many dictionaries.

  46. 164da498c05ca013c9e2e3821dfd3cd4 by earthsound · · Score: 1

    1fc011b3e5eadb933cc028aebd5a178f

  47. Even on diskette, syskey is broken-ish by Anonymous Coward · · Score: 0

    If you've rooted the system anyway, you can debug the LSASS service and extract the plaintext SAM database.

    Having the syskey on separate media does help you if your opponent has stolen a hard disk or backup tape though...

  48. Evil Pop-ups warning... by hughk · · Score: 1
    I have a confession. At work, I must use IE. On the otherhand, MD5 is interesting from a work perspective.

    When I try to access the plugged website, it is full of evil pop-ups that try to force you to download expensive internet access tools.

    --
    See my journal, I write things there
  49. Another Reason.... by HopeOS · · Score: 2, Informative

    3) the system administrators need reasonable deniability from user's claims of password theft.

    If the user's password is stored in plain text, they can claim that you, the system administrator, have access to it. This increases your liability as the user can now disclaim responsibility for actions taken with that password, on any other system where it is used -- after all, they could have been impersonated, and they can accuse you of being the culprit.

    -Hope

  50. Don't use the username as salt by Paul+Crowley · · Score: 1

    Use a random salt - that way, the salt changes every time you change your password, and the probability that two entries anywhere in the world have the same salt by accident can be bounded.

  51. Great example of a comprimised database. by azimir · · Score: 1

    From an NIS perspective, you *must* encrypt into the database.

    If you've ever poked around an NIS environment, give this one a try:

    ypcat passwd

    Viola! It spits out the entire password file! Fire up John the Ripper and go to town. Built in compromised password databases.

  52. First WTH is wrong with you people Post by Anonymous Coward · · Score: 0

    (see: subject)

  53. AOL Instant Messenger by DavidLeeRoth · · Score: 1

    In the Windows XP registry (Start>Run>regedt32.exe), under HKEY_CURRENT_USER\Software\America Online\AOL InstantMesseger\CurrentVersion\Users\(screenname)\ Login, there is a config called Password1. If you have your passwords saved on the computer, a password will be there in an md5 salted hash. This site will take that hash and unsalt it. It will aslo attempt to crack it. If that fails, at least you have an md5 hash that is pure. I have always wanted to know how this site works, so if anyone wants to hit me with some knowledge, or maybe some code, I would love it.

  54. Not so. by Paul+Crowley · · Score: 1

    No, the chances of entering a loop after 65536 hashes are roughly 2^-129. If you're using a 160-bit hash then you'd likely have to hash 2^80 times or so before reaching a value you'd seen before.

    Passwords are generally so pathetic that even five bits are worth having, but fifteen or even twenty bits are practical if you don't mind a tiny bit of extra server load when verifying a password.

    1. Re:Not so. by Anonymous Coward · · Score: 0

      [No, the chances of entering a loop after 65536 hashes are roughly 2^-129]

      Unfortunately this isn't right.
      You are thinking the chance of actually having looped at least once, which is irrelevant. The loop is probably going to have a length of around 2^64 (MD5) to 2^80 (SHA1). Worse, there are _lots_ of those loops, enough to ensure you have entered one after 64k iterations.

      Then the cracker just needs to:

      for (tmp = H(pwdhash), looplen=1; tmp!=pwdhash; tmp = H(tmp)) looplen++;
      for (answer = tmp, cnt = 65536; cnt!=0; cnt = (cnt+1)%looplen) answer = H(answer);

    2. Re:Not so. by Paul+Crowley · · Score: 1

      No, the probability you'll have even entered the loop after 65536 iterations is still very low, though calculating it is harder.

      I think on some level you're thinking as if the hash function was bijective; that's the only way your "crack" would work. Of course if it were, the expected length of the loop would be 2^159 (or 2^127 if you're using MD5). Why don't you try testing it? Use a "hash function" that truncates its output to, say, 10 bits, so you can see why it doesn't work (and cut down the number of iterations to a suitable number too)

      If you find an attack on Kelsey, Schneier et al's technique, publish. But so far you haven't.

    3. Re:Not so. by Paul+Crowley · · Score: 1

      Just done some sums and I can place an upper bound on the probablility of being in the loop after 65536 iterations of 3.49245965481e-10 - this is the sum of the probability that you will come back to a pre-existing value after fewer than 2^48 iterations, plus the probability that when you come back you hit the first 65536 iterations, given that you take more than 2^48 iterations to do it. That's for a 128-bit hash; for a 160 bit hash it's much less likely again.

    4. Re:Not so. by Anonymous Coward · · Score: 0

      No, the probability you'll have even entered the loop after 65536 iterations is still very low, though calculating it is harder.

      Well, damn. I expected that at least 2^(3N/4) of hashes would have belonged to loops (which now I realize in case of MD5 would have meant that one out of every 2^32 keys would have been be crackable even without repeated hashing), but turns out that it isn't so. I guess this is because when significantly more than 2^(N/2) keys belong to the loops, the likelyhood of a new hash series hitting itself before one of those diminishes exponentially rather than just reciprocally which would have made it just another birthday problem.

      I think on some level you're thinking as if the hash function was bijective; that's the only way your "crack" would work

      What are you after?

      -user supplies pwd
      -the server stores in the password file H^65536(pwd).
      -cracker gets his hands to the file and finds out that H^65536(pwd) happens to be the same as H^100065536(pwd).
      -cracker calculates H^100000000(pwd) by applying H() 99934464 times on H^65536(pwd).
      -this is not likely to be the same as pwd, but it has the magical property that H^65536(H^100000000(pwd)) happens to be the same as H^65536(pwd)
      -therefore the server is going to let the cracker in with that bogus password.

      Why don't you try testing it?

      Now that you insisted, I did, using 32-bit hashes. Works nicely, with the obvious exception that I had to bloat the number of initial hashings:(

      If you find an attack on Kelsey, Schneier et al's technique, publish. But so far you haven't.

      Googling them doesn't seem to yield anything relevant to this. Which I don't see terribly surprising because no-one would actually use this system unmodified. It's so easy to e.g. throw in a round number which breaks this attack completely.

    5. Re:Not so. by Paul+Crowley · · Score: 1

      It's the link I provided at the start: http://www.schneier.com/paper-low-entropy.html

      As I've shown, this attack doesn't work, because the probability that you're in the loop at that stage is too low, and in any case it requires 2^80 work with a 2^160 bit hash, which is impractical. If your demonstration is correctly implemented it should show the same thing - how many iterations did you test it with? With a 32-bit hash, 20 iterations or so should show this effect.

      If you find an attack that does work, please do publish it!

    6. Re:Not so. by Paul+Crowley · · Score: 1

      My calculations indicate that with a 32-bit hash, even if you use 1000 iterations the chances that you'll be able to loop around and find a preimage of H^1000(x) are less than 0.02. That's a slight approximation but I can't see that it'll be off by much. If you're interested in pursuing this further, why not copy your code into pastebin.net or similar and I can help you debug it?

      This comment thread will be closed soon, so email me and let me know. You might also want to put your name to a comment - after all, if you have found an attack, it should be credited to you.

  55. Hashes and Collisions by Gyorg_Lavode · · Score: 1
    Is it really required that hash functions used for passwords have collisions? Why hasn't anyone developed a hashing algorithm designed to have zero collisions when hashing something less than the length of the hash. If a hash is 256 values long in the same character-space as the password, theoretically you could have a 1-1 correlation. Is this technically possible in application?

    (Oh, and does anyone have a good site to find word lists and rule lists for john the ripper? I always have trouble finding a really good rule list.)

    --
    I do security
  56. That isn't that many hashes. by Anonymous Coward · · Score: 0

    Considering your average P4 can spit out single MD5 hashes at a rate of ~500k per second for just the crypts with the crappy openssl implementation. One could generate that to disk in approx 10 times that amount of time due to latency of disks. Sorting could be done with a hash like storage system of directories. All and all this is a poor article and that could be generated in a matter of days with any one of the computers you pick up for 200 euro. Slashdot has poor articles lately. Forgive my english.

  57. Salt an Sleep? by Anonymous Coward · · Score: 0

    Why bother iterating (bringing down your performance)?

    Why not just sleep for a couple of seconds instead?

    You get the same slowdown but your server is happier.

    Or am I not getting something?

    1. Re:Salt an Sleep? by Paul+Crowley · · Score: 1

      Only if the password verifier is secret. If it is public (such as if the password is used to encrypt a message) or if attackers break in and get hold of it, this technique will slow down a dictionary attack.

  58. Easy Enough to Defeat by Lotharus · · Score: 1

    This probably oughtn't be a top-level comment, but I didn't have the time to dig down to find a more appropriate place for it.

    From an attack vector perspective, it seems pretty easy to defeat in a pretty simple way; all one really needs to do is mangle the hash in some predictable way. I wrote a Java class that inadvertently mangles (on average) half the bytes of an MD5 hash (swaps some bits around) because of some bonehead logic on my part converting unsigned bytes into hex strings. Since it mangles it the same way every time, it still functions perfectly, but its output is not a plain MD5 hash. I went through a series of hashes created by that class at the FA's website, and not one of them returned a hit.

    Sure it's simplistic, it's security by obscurity, etc. etc. etc., but it's mostly effective against an attack based on precalculated hashes. An attacker would not only need to intercept the hash, but also the pattern for mangling it (entirely possible, but one more hurdle at least).

    Not to mention that any of a number of other tricks, such as have been already mentioned (salting, hashing a concatenation of username/password, etc), would be equally effective.

    I'll probably get modded down for Redundant or Boneheaded or Naive, but that's what's great about Slashdot. I can make my boneheaded opinions known with impugnity!

    So anyway, yeah.. Should be a quick "yikes!" for anyone simply poking md5($pass) into a db, but otherwise, blah. Interesting way to chew up a huge amount of storage space, but not terribly exciting until they map all 2 ^ 128 possible hashes (over 3.402 x 10 ^ 38).

  59. Done before, and ten times better by kimihia · · Score: 1

    This has been done before, and with over twice the size:

    http://us.md5.crysm.net/stats

    Has 32,106,390 entries.

    The New Zealand mirror has some 25 million entries or so.

    Small fry.

    There are also explanations on there of how to avoid this sort of attack, by use of proper salt, and md5(pass + md5(pass)), all the usual improvements.

    http://saf.crysm.net/

    1. Re:Done before, and ten times better by Anonymous Coward · · Score: 0

      Ok, the reason they didnt get anywhere:
      md5("word")="c47d187067c6cf953245f128b5fde62a"

      Result on thier site:

      For the md5 c47d187067c6cf953245f128b5fde62a these results found:

      Elapsed: 0.264652 seconds

      No results and noticably slower.