Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Letters-Only LM Hash Database 237

Posted by CmdrTaco from the need-new-security dept.
Peter Clark writes "Disk storage has increased tremendously in the past 5 years and the blatant insecurities in the antiquated LM hashing technique have not gone away; though functionality has been added to disable LM hashes, this is not set by default. With some help from Elcomsoft, simple flat files have been created that hold every combination of LM hash for letters only passwords. Jesko has coded a server application which allows you to access this database. Simply telnet to: beginningtoseethelight.no-ip.org on port 2501 and paste in a LM hash. So how does this differ from Rainbow tables? Well this will return a password 100% of the time, using minimal processor power, in approximately less than 0.2 seconds."
This discussion has been archived. No new comments can be posted.

Letters-Only LM Hash Database More

Letters-Only LM Hash Database

Comments Filter:

  • less than 0.2 seconds (Score:5, Funny)

    by Sediyama ( 527384 ) on Tuesday November 02, 2004 @12:24PM (#10700861)
    I think someone is underestimating the /. effect.

  • Someone explain? (Score:5, Insightful)

    by mistersooreams ( 811324 ) on Tuesday November 02, 2004 @12:24PM (#10700866) Homepage
    Anyone feel that a article summary with this much technical detail should have some links or explanation of what it's actually talking about? And since I'm one of the ignorati who doesn't understand, could some please explain to me?

    • Re:Someone explain? (Score:5, Informative)

      by Jaruzel ( 804522 ) on Tuesday November 02, 2004 @12:28PM (#10700922) Homepage Journal
      As I understand it LM Hashes can't be reversed. So what someone has done here is pre-hashed an entire dictionary, and created a word=hash lookup system.

      You telnet to it, feed it the hash, and it replies with the word.

      LM hashes are how a lot of passwords are 'encrypted'

      Excuse the fuzzy description... Crypto is not my strong point.

      • Re:Someone explain? (Score:4, Informative)

        by gweihir ( 88907 ) on Tuesday November 02, 2004 @01:27PM (#10701681)
        As I understand it LM Hashes can't be reversed.

        That is untrue. Any hash can be reversed in the sense that you can generate an input that will result in a specific output. However the input may not be the only one generating that output and it may be computationally infeasible to do this for sufficiently random original inputs to the hash. The property of a (theoretical) perfectly secure hash is that you have to try possible inputs and hash them until you are lucky.

        In other cases you might actually be able to reverse the algorithm itself and do without trying a lot of inputs. A hash were this is possible with significantly less effort is usually called "broken".

        So what someone has done here is pre-hashed an entire dictionary, and created a word=hash lookup system.

        Yes, that is called a "Dictionary Attack", and the dictionary is a function reversing the hash and given in the form of a table. Quite an old technique. But since LM hashes are not very secure, the possibility to do this is not surprising to anybody in the field.

        • That is NOT "reversing a hash" (-1, Misinformed) (Score:5, Informative)

          by sczimme ( 603413 ) on Tuesday November 02, 2004 @02:33PM (#10702726)

          That is untrue. Any hash can be reversed in the sense that you can generate an input that will result in a specific output.

          That is NOT reversing the hash: this should be painfully bloody obvious since the process you describe runs the same hash in the same manner.

          Reversing a hash - meaning you start w/ the hash and work backwards to recreate the original data - is impossible. Bits are lost during the hash process, and there is no data in the hash that will allow those bits to be reconstructed. Read _Applied_Cryptography_ by Bruce Schneier, or at least read any of the many crypto/hash FAQs available on the web. NIST [nist.gov] has some good papers available.
          • Bits don't have to be lost for a hash. Usually they are, but not always. Bits are lost because hash functions are normally designed to take an any length string and return a fixed length string. This is not always the case, however. With the LM hash specifically, the maximum input is 15 characters. While I do not know the precise algorithm used with LM, there is no reason that data must be lost by it.

    • Re:Someone explain? (Score:5, Informative)

      by Anonymous Coward on Tuesday November 02, 2004 @12:32PM (#10700967)
      http://en.wikipedia.org/wiki/Lm_hash [wikipedia.org]

    • Re:Someone explain? (Score:5, Informative)

      by terraformer ( 617565 ) <tpb@pervici.com> on Tuesday November 02, 2004 @12:32PM (#10700969) Journal
      They are talking about the hashing algorithm MS uses on Windoze machines and networking. LM stands for LanManager which is what the networking component in windows has been called since as far back as I can remember. What I wish people would do is send up some examples to test out. Those without regular access to windows would benefit greatly. Also, I wish I could shed some more light on the letters only thing, but I am confused as to whether that is for the hashed passwd or the hash itself. I suspect it may be the passwd itself but I am not sure since it is not clear.

      • Re:Someone explain? (Score:5, Funny)

        by Doctor Memory ( 6336 ) on Tuesday November 02, 2004 @12:36PM (#10700998)
        I suspect it may be the passwd itself but I am not sure since it is not clear.

        Of course it's not clear, it's been hashed -- haven't you been following along?
      • They are talking about the hashing algorithm MS uses on Windoze machines and networking

        The hashing algorithm used since NT4SP3 and Win2K is NTLMv2, whereas "lanman" is NTLMv1. NTLMv2 is significantly more secure, however, for backward compatibility with older Windows 9x machines some companies still use NTLMv1.

        • Re:Someone explain? (Score:5, Informative)

          by afidel ( 530433 ) on Tuesday November 02, 2004 @01:31PM (#10701750)
          however, for backward compatibility with older Windows 9x machines some companies still use NTLMv1.

          Actually by default all passwords shorter than 14 characters are stored as BOTH LMv2 AND LMv1 hashes in the registry and both are valid for authentication if they are present. This is true for both Windows Server 2000 and Server 2003. You CAN disable the storage of LMv1 hashes but that does not remove any existing hashes from the SAM, you would also need to force LMv2 authentication and even then someone who could steal the SAM file could get the plaintext.

          • You CAN disable the storage of LMv1 hashes but that does not remove any existing hashes from the SAM, you would also need to force LMv2 authentication and even then someone who could steal the SAM file could get the plaintext.

            I think in most cases simply turning off LM authentication altogether is sufficient. Sure, if someone could steal the SAM file, then they would get the existing hashes. However, if an attacker can get this kind of access to your system, then you have bigger problems. With this kind

          • Er, this [microsoft.com] page says that there is only one type of LM hash and two versions of NTLM. LM is supported for DOS, the original Lan Manager, and 9x. NTLM_V1 is supported on all versions of NT and NTLM_V2 is on NT4 SP3 and 9x with the Active Directory client update.

      • Re:Someone explain? (Score:3, Informative)

        by Foolhardy ( 664051 )
        To stop this compatibility behavior, see the MS knowledge base article Q299656 [microsoft.com].

        Basically, you want the security policy "Network security: Do not store LAN Manager hash value on next password change." in Group Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options.
        Or you can set the registry value the policy sets directly: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\NoLMHash.
        Note that on 2000 and earlier, this prevents only the cre

    • Re:Someone explain? (Score:5, Informative)

      by Dun Malg ( 230075 ) on Tuesday November 02, 2004 @12:35PM (#10700996) Homepage
      Anyone feel that a article summary with this much technical detail should have some links or explanation of what it's actually talking about? And since I'm one of the ignorati who doesn't understand, could some please explain to me?

      In simple terms, a hash is a sort of "one-way" function. Passwords are often saved as hashes. THe password is fed in one end, and the hash comes out the other. The hash is saved in a file. When one logs in and types in one's password, the system feeds what you typed in through the hash function and checks if the result matches the hash of your password. Since there is no way to reverse the hash process, it's been considered fairly safe to leave these hashes moderately unprotected. This database is, presumably, a sorted collection of the possible hashes from all letters-only passwords up to a certain length. The hash can't be reversed to get the password it came from, but a huge database of all possible hashes and their originating passwords certainly makes that irrelevant.

      • Re:Someone explain? (Score:4, Informative)

        by gclef ( 96311 ) on Tuesday November 02, 2004 @12:48PM (#10701151)
        This database is, presumably, a sorted collection of the possible hashes from all letters-only passwords up to a certain length

        Actually, last time I checked, most versions of windows that used LanManager hashes split the password string into a new hash every 7 characters (yes, that is incredibly stupid). In other words, if your password was 8 characters long, there would be two hashes for your password: one that covered the first 7 characters, and one that covered the last 1 character.

        So, I would assume the folks here have done every letter combination for up to 7 character long passwords, since that's all they'd need to do.

        • So, I would assume the folks here have done every letter combination for up to 7 character long passwords, since that's all they'd need to do.

          Yep. The 124 Billion Names of Bill Gates.

    • LM hashes are Lan Master hashes, an old microsoft standard.

      They're not used much anymore because they're ludicrously insecure yet windows still makes a LM hash of all passwords by default. You can easly get someone's (administrator) password from these hashes, and the hashes aren't hard to get from a computer.

      They're not used and can give others your password, and now there's a site that'll give you any letters only password from it's hash in seconds.
      • They are used a lot more than you'd think, because if you still have Win9x boxes on your network (and lots do - I discontinued my last Win95 box last month) then you have to use LM hashes.

    • Instead of using the brute-force computing approach of generating hashes and comparing them to the known hash (looking for a match), this process uses an already created list or table of passwds and their associated hashes. Creating the table is computationally and storage[ally] non-trivial, but once it is in place cracking a passwd is as easy as grep-ing through the list/table to find the known hash.

      Nutshell:

      cracking passwds individually: no up front work and extremely variable cracking time

      crea

    • Right on! Isn't there are "rule" somewhere about using the full form of an acronym before using the acronym?

      A google for LM comes up with all kinds of things. Logistics Management, Land Mines.
    • I've written up the whole thing:

      There are two things people always forget about LM Hashes:

      1. They are not exposed on the wire.
      2. They are password equivalent.

      The LM logon protocol is challenge/response. The server sends a random 8-byte string (the challenge) and both client and server encrypt it. The client sends back the result (the response) and the server checks to see if the responses match. If so, you're in.

      Note that the hash is not sent over the wire.

      T

  • of course... (Score:4, Insightful)

    by Qwerpafw ( 315600 ) on Tuesday November 02, 2004 @12:27PM (#10700892) Homepage
    The files increase exponentially in size for passwords which include numeric characters. While the security risk exists, good password design obviously minimizes it. People aren't going to be lugging around terabyte-sized password database files.

    • Re:of course... (Score:5, Insightful)

      by Jeffrey Baker ( 6191 ) on Tuesday November 02, 2004 @12:36PM (#10701006)
      Why not? A terabyte fits in a briefcase these days, and a remote attacker is not constrained by space. A petabyte of storage is barely one rack's worth and not very expensive, either.
    • People aren't going to be lugging around terabyte-sized password database files.
      Not yet they aren't, but it's not unreasonable to expect that someday they will. Then again, one would hope by that point sufficient encryption would exist such that anything vulnerable would have been replaced. It's not like people continue to run unpatched legacy systems nowadays. . .
    • People aren't going to be lugging around terabyte-sized password database files.

      I thought that was the whole point of this exercise - that a centrally-available hash master was viable.

      And just out of curiosity, wouldn't the master file be really compressible?

      GTRacer
      - My PW's have always included numbers and often punctuation just for this reason

      • Re:of course... (Score:3, Informative)

        by cduffy ( 652 )
        And just out of curiosity, wouldn't the master file be really compressible?

        Not really -- good hashes act random.
        • Of course, the portion of the master file with the password combinations would compress fairly well.
          • Not really, you'd sort the hashes in order to make looking them up quick - this means that password 'aaaa' and 'aaab' would likely be half the file apart. In other words, too random for the compression algorithm to take advantage of. Of course, you're only going passwords which are letters+numbers, so that's only 5.2 bits of data per byte and will compress fairly well because of that, but not as well as a list of 'aaaa' 'aaab' 'aaac' etc.
    • You don't have to lug a database around, you set it up somewhere and access it using a web interface or something like that. A terabyte really is not that much information anymore; you can buy a firewire terabyte drive that you can hold in your hand (though it's kinda heavy) for $800. A hundred terabytes for the database with all special characters is probably out of reach for most people for now, but for a business it's no problem. And one terabyte for all letters and numbers is quite doable for any cra
      • Which just ignores the fact that you only have to have ONE valid password per hash in order to crack it. That password may be complete gibberish, but it'll still work to log you in untraceably.

        Say there's 36 valid hash characters, then

        36^7 which I calculate as:

        78,364,164,096. 78 billion hash combinations.

        78.3b * 7 = 548 Billion x 2 for character mapping

        = 1.1 TB.

        Plus some overhead

        You'll be able to fit this on a laptop in 2 years.

    • Re:of course... (Score:3, Interesting)

      by Corrado ( 64013 )

      People aren't going to be lugging around terabyte-sized password database files.

      But they wouldn't need to. All you need is a telnet client and a network connection. And there is no reason that one couldn't add to the existing files.

      In fact, this would be a really cool project to break up into pieces. Bob takes everything starting with A|a, Steve takes B|b, etc... Then just build a front end (accessable via telnet) that passes each query off to each back end and returns the results. You could even hac

    • .... or the guy could just lug around a mobile phone with a j2me telnet client and access some breaker elsewhere...

      or do it later or whatever.
    • While the security risk exists, good password design obviously minimizes it.

      Good password design:
      1. disable NTLM
      2. use 15+ character passwords.
      3. dont write you password on a post-it note and attach it to the bottom side of your keyboard

  • Non sequitur? (Score:3, Insightful)

    by Nighttime ( 231023 ) on Tuesday November 02, 2004 @12:28PM (#10700921) Homepage Journal
    Disk storage has increased tremendously in the past 5 years and the blatant insecurities in the antiquated LM hashing technique have not gone away;

    Maybe I'm being a bit thick here but how does the first part of that sentence relate to the other?
    • I beleive it means that you can make a lookup table relatively cheaply, rather than having to generate it on demand, and thus greatly speed up the LM hacking.

    • Re:Non sequitur? (Score:5, Informative)

      by stray ( 73778 ) on Tuesday November 02, 2004 @12:34PM (#10700985) Homepage
      it's all about a time/space trade-off:

      - you have a password hash you want to crack

      you can either:

      - brute force your way through a long list of possible passwords to find one that matches the hash; everytime you do this, it takes a lot of time and processing power

      - or you can go through all possible passwords ONCE and save the resulting hashes; subsequent cracking jobs are very fast, but you wasted a lot of space to store all possible hashes.

      thus, if disk space is cheap and you can afford to keep a couple of gigs in pre-computed hashes around, you have a very fast way of cracking weak hashes. a couple of years ago, this was not possible due to hard drives being like 200MB large.
      • - or you can go through all possible passwords ONCE and save the resulting hashes; subsequent cracking jobs are very fast, but you wasted a lot of space to store all possible hashes.

        thus, if disk space is cheap and you can afford to keep a couple of gigs in pre-computed hashes around, you have a very fast way of cracking weak hashes. a couple of years ago, this was not possible due to hard drives being like 200MB large.
        You could always burn the data on a DVD rom. That would give you around 7 Gigabytes to
      • a couple of years ago, this was not possible due to hard drives being like 200MB large

        I think you mean 200GB.

    • Clear writing is a lost art... (Score:5, Interesting)

      by NotQuiteReal ( 608241 ) on Tuesday November 02, 2004 @01:24PM (#10701645) Journal
      If the article were written more along these lines;

      It is well known that the LM (LanManager password) hashing technique used by older Windows OSes (thru WinMe) is insecure. Now someone has really pointed this out by simply saving all possible password hashed in a database made possible with today's cheap, large disk drives...

      But that wouldn't be nearly as much fun - by being vague you get many more posts correcting grammar, explaining what should have been there in the first place, etc.

      In short, better writing might promote more useful comment posts, and we wouldn't want that on Slashdot.

  • modeling unknown passwords (Score:5, Interesting)

    by strook ( 634807 ) on Tuesday November 02, 2004 @12:32PM (#10700966)
    There's gotta be a better way to model what a user's password can be than just all combinations of only letters, or a list of common passwords plus substitutions. I think these are the only ones I've seen. But this doesn't really reflect that "fiqojeio" is a much less likely password than say "foo7bar+".

    I think this sort of attack could get much stronger than people expect if there was some sort of Markov-process-ish way of generating plausible passwords. I mean, if Google can guess when you spelled something wrong, these programs should be able to figure out which strings are more likely to be passwords. Or maybe I'm overgeneralizing by how I pick my own passwords....
    • There's gotta be a better way to model what a user's password can be than just all combinations of only letters, or a list of common passwords plus substitutions. I think these are the only ones I've seen. But this doesn't really reflect that "fiqojeio" is a much less likely password than say "foo7bar+".

      I see this as mostly just a harbinger of Things To Come. At what point will it become a trivial matter to generate a database of all possible hashes of all possible passwords (incl. all symbols and numbers

    • Your example "foo7bar+" is pretty easy to crack. LM breaks passwords into 7-character parts, so you just need to break "foo7bar", which is reasonably easy to do, and "+", which is trivial. (Yes I had my password broken this way once. I kept the complexity at the end. Bad move. Now I know better.)
    • I'm not sure why this modded insightful. The point is that with this method you can crack all passwords containing just letters instantly. The obvious extension of this is building hash tables that will allow you to crack all passwords instantly. The space to contain those hash tables is not quite within reach of the average cracker yet...but it most certainly will be sooner or later.

      If you want a program that figures out which strings are likely to be passwords, use l0phtcrack which incorporates a dict
    • My understanding of the article is that "fiqojeio" would be in the DB and therefore is instantly crackable.

      The point of the article isn't that "fiqojeio" is better or worse than "foo7bar+". It is that LM hashing method is weak and should not be used.

    • much less likely password

      Yes, much less likely, but people sometimes choose things like that for their passwords anyway. My wife's self-chosen password to her bank account, for example, is 'Nfok3G!~qOmp', and I can tell you that NOBODY is going to guess that one!

  • I tend to use 6-8 characters.
    Numbers, upper and lower case letters.
    so 62^+62^7+62^8 =2.12x10^14 combinations.
    I think I'm okay for a while.
    Multicase passwords do HUGE things to the statistics of the problem.

    • Re:My passwords (Score:5, Informative)

      by kidgenius ( 704962 ) on Tuesday November 02, 2004 @12:57PM (#10701263)
      Multicase passwords do HUGE things to the statistics of the problem.

      Normally, yes. But the LM method converts everything to uppercase before hashing. So your 8 character password, that had 10^14 combinations has just been reduced down to (26+10)^8... combinations or 2.9*10^12. Now, you might be saying "That was only a factor of four drop, no big deal, still 10^12 combos left. Realize though, that this DB currently has all possible passwords of a maximum length of 15 characters. This is 2.8*10^13 combos. This is less than the 10^12 possibilities that your password has. Consider that it searches in 0.2 seconds, and your password is not so safe.

    • Re:My passwords (Score:2, Informative)

      by DBA_01123 ( 770195 )
      If LMv1 hashes are enabled then a *case insensitive* hash of your password is there to be matched against. Even if the server isn't using them having them there at all is a HUGE hint as to what your password is. Find a match for the case insensitive hash then work through the possible case permutations of it till you get a match for the case sensitive hash. It's several orders of magnitude easier than directly going after the case senstive hash.

    • Re:My passwords (Score:5, Informative)

      by delta407 ( 518868 ) <(slashdot) (at) (lerfjhax.com)> on Tuesday November 02, 2004 @12:57PM (#10701272) Homepage
      Multicase passwords do HUGE things to the statistics of the problem.
      That's why Microsoft's LM hashing algorithm is so cool -- it uppercases your password before hashing. With this algorithm, multicase passwords do nothing to the statistics.
      I think I'm okay for a while.
      You're okay for about 2 hours and 34 minutes: that's how long it takes to traverse every possible alphanumeric input on the author's test rig. Additionally, the article suggests that tables including every possible LM hash for [A-Z0-9] would occupy only 1.2 TB of space, meaning that these lookups could be done in a matter of milliseconds instead.
      • That's why Microsoft's LM hashing algorithm is so cool -- it uppercases your password before hashing. With this algorithm, multicase passwords do nothing to the statistics.

        Please, please tell me you are joking.

        I am no fan of MicroSoft, but come on, no one would really do something like this.

        I figured that my passwords are safe because they are normally the tunes of music..

        For example

        Taaaah-dum+dum*dum#dum#taaaaah|dum!tum^d u m$tum%rumtittytum.

        And since I am tone deaf, It's not very likey that someone will

        • LM hashes every 7 characters separately, in order to lower the Total Cost of 0wn3rship.

        • Re:Holy Ratshit, Batman! (Score:5, Interesting)

          by Oestergaard ( 3005 ) on Tuesday November 02, 2004 @01:46PM (#10701952) Homepage
          He is not joking. And he didn't tell the whole story either; there are several either tremendous stupidities in the LM hash which makes long passwords worthless, and relatively short ones easier to break than their length would otherwise indicate (separate grouping of characters, triple-DES'ed *independently*).

          The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.

          So, if someone placed a link on their homepage to a patched Samba which logged LM hashes, they could gather LM hashes from most of their windows using visitors.

          This would *include* those behind many firewalls, because many default firewall setups will allow *outgoing* connections - and in this particular case, it is indeed the windows client that is initiating the connection to the remote web server in order to send away the current users LM hash (along with username, domain, local machine name and other goodies).

          Yes, I told CERT about this some three years ago. They wouldn't touch it with a five foot pole. I then told Microsoft about it. Their response was something like "fixing that problem would require us to re-design our windows networking layer - therefore it is not a security problem".

          Well, there you have it.

          But hey, if you're on Windows you're fucked anyway, and none of this should really come as a shock to you :)
          • This is all very true, and I won't try to defend it. But, and this is a big but, does it really matter if some guy on a remote website gets my password? First, my IP is dynamic, so they're only going to have so long to attack before I vanish. Second, they have to get through my firewall. I have no ports open to incoming connections. Then, they're going to have to find a useful service which they can use the password with. Seeing as my SMB shares are all on non-routable interfaces I'm not sure how easy that
            • Assuming the average user does not re-use passwords on multiple systems, that there is no wireless, and that the attacker won't simply automate the attack to log in (if possible back thru the firewalls) next time the user visits.

              Sure, then you're sort of right I guess :)

              Basically, you're safe because you're one fish in a million. The chance of getting eaten is very small.

              Unless you're not just a little fish - if someone keeps a database of LM hashes (and user name, domain, machine name, IP, ...) it shoul
          • >> The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.

            So, can you post a link explaining how to disable this as part of a non-default install? I'm not sure I've ever seen this before.

            • Here's how (Score:5, Informative)

              by Foolhardy ( 664051 ) <csmith32@gmai l . com> on Tuesday November 02, 2004 @03:40PM (#10703683)
              In the local Security Policy->Security Options, you want to change "Network security: Lan Manager authentication level" to at least "Send NTLM response only". Or the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\LmCompatibilityLevel to at least 2.

              See this [microsoft.com] page for this and related policies.
              This [microsoft.com] for an overview of LM, NTLM and NTLMv2.
              And here [microsoft.com] to see how to prevent storage of LM hashes.

    • Re:My passwords (Score:3, Interesting)

      by Pete (big-pete) ( 253496 ) *

      I tend to use 6-8 characters.
      Numbers, upper and lower case letters.

      I tend to use uppercase, lowercase, numbers, and punctuation. An example might look like: s1mhm$tM-BIdc! (just off the top of my head, and memorable to me)

      Most people do have horrific password security though...

      -- Pete.

  • This just in from beginningtoseethelight... (Score:5, Funny)

    by jmcneill ( 256391 ) on Tuesday November 02, 2004 @12:40PM (#10701045) Homepage
    Dear Slashdot Readers,

    Thank you for letting us know your passwords.

    Regards,
    The staff of beginningtoseethelight

  • Light? (Score:2, Funny)

    by alapalaya ( 561911 )
    in the article:

    beginningtoseethelight.no-ip.org

    the /. fortune:

    The light at the end of the tunnel is the headlight of an approaching train.

    Am I the only one to see a connection ?


  • awright! (Score:5, Funny)

    by sootman ( 158191 ) on Tuesday November 02, 2004 @12:47PM (#10701139) Homepage Journal
    now we're gonna kick it old-skool and /. a telnet server! woo hoo, just like the old days! our next target: gopher://sunsite.unc.edu

  • Whew! I'm still safe (Score:5, Funny)

    by DongleFondle ( 655040 ) on Tuesday November 02, 2004 @12:48PM (#10701148)
    I guess I'm still relatively safe though because my admin password is not only 10 characters long, but has capitals, lower case, numbers and symbols in random order.

    Its H82sd*e2Tn.

    Nobody is ever going to crack that!!!

  • Disable LM Hash (Score:5, Informative)

    by mixmasterjake ( 745969 ) on Tuesday November 02, 2004 @12:48PM (#10701149)
    Unless you have machines on your network running 95/98 you should disable LM Hash in Windows. It is there only for backwards compatibility and you can disable it easily:

    http://support.microsoft.com/default.aspx?scid=KB; EN-US;q299656 [microsoft.com]

    • Yes, LM hashed passwords have been insecure for years, since L0phtCrack came out. Since then, as processor power has increased, it has only gotten quicker to crack passwords.

      If you have 95/98 machines on your NT or 2000 network, your passwords are not secure, period.

  • Hashes (Score:5, Insightful)

    by CastrTroy ( 595695 ) on Tuesday November 02, 2004 @12:49PM (#10701169)
    I had a thought last month, when there was news of duplicates being found in the MD5 hash. For security purposes, couldn't we just use the MD5 hash along with the SHA1 hash. Would there be any string of data which held the same hash for both MD5 and SHA1? This could help increase the power of digital signatures. Anyway, this database of hashes and passwords only works for letter-only passwords, which are assumed to be quite easy to brute force anyway.
    • Storing two hashes isn't worthwhile. At best it can only double the amount of time taken to come up with a matching password.

      Might as well just check the SHA1 hash. You won't gain anything by checking the MD5 hash as well.
    • I had a thought last month, when there was news of duplicates being found in the MD5 hash. For security purposes, couldn't we just use the MD5 hash along with the SHA1 hash
      I we think MD5 is too weak, we have to move to a stronger hash. MD5+SHA1 is not necessarily the best replacement.
      Would there be any string of data which held the same hash for both MD5 and SHA1?
      If you mean that 2 strings can have both the same MD5 ad the same SHA1, given the space of hashable data is at least as big as the space of has
    • Would there be any string of data which held the same hash for both MD5 and SHA1?

      yes there would. an MD5 hash is 32 hexadecimal digits, or 16 bytes. i'm not sure off the top of my head if SHA1 is the same, but for purposes of argument we will assume that it is. (regardless, it is a fixed number of characters from a finite set of possible characters, which is the main point here.)

      so if we combine an MD5 hash and an SHA1 hash, we have essentially a 32 byte signature. Now if you are only using this to s

  • How long until... (Score:3, Funny)

    by rewt66 ( 738525 ) on Tuesday November 02, 2004 @12:49PM (#10701177)
    beginningtoseethelight gets hit with a DMCA lawsuit?

    And, yes, I am aware of the irony of posting this on election day in the US...
  • So how long before this becomes a Windows.NET Web-Service? Then all the hackers can struggle with Visual Studio .NET 2003.
  • Cool. Now, where's the .torrent that allows me to download those files? :)
  • I think it'd be interesting to see this available via a DNS request, similar to how a number of black hole lists (RBLs) handle lookups.
  • There is an interesting entry in Robert Hensing's Incident Response blog [asp.net] about using passphrases to avoid using the NTLM hash. He is a microsoftie but what he says makes sense. I've since switched to using passphrases over 14 characters and so far have not be able to crack them with rainbow tables.

    if your interested in a rainbow table demo one can be found here [lasecwww.epfl.ch]
  • Oddly enough, I was going to start a similar project for SHA and MD5 hashes. Sure, the DB would be huge... But huge is easily dealt with. At 4 gigabytes per DVD-R (I know, I'm such a n00b, haven't gone dual-layer yet), .zip allowing compression to 2/3rds of disk space, that's about 64 million passwords per DVD.

    One DVD could easily handle:
    Every Zip
    Every 7-digit phone number
    Every word in the dictionary (Upper, lower, and Capitalized)

    Move up to a 2 disc set and get:
    Every date

    With a little work it'd probabl

  • It doesn't matter. Really. (Score:5, Informative)

    by juan large moose ( 27329 ) on Tuesday November 02, 2004 @03:43PM (#10703710) Homepage
    The LM and NTLM hashes are password equivalent.

    If you have the LM Hash, and the server accepts LM Authentication, you don't need the password. At all.

    Likewise, if you have the NTLM Hash, and the server accepts NTLM, NTLMv2, or LMv2 authentication, then you don't need the password.

    The hashes are password equivalent.

    I've written it all up in my online book [ubiqx.org] (slashdot review [slashdot.org]), but...

    Basically, the hashes are generated with no salt...nothing to obfuscate them. The algorithm used to log in is challenge/response:

    • The server sends a random 8-byte string (the "challenge").
    • Both client and server encrypt the challenge using the LM and/or NTLM Hash, not the password.
    • The client sends its result (the "response") back to the server.
    • The server compares results. If they match, the server grants access.

    So... The hash is not exposed on the wire. It has to be reversed from the challenge and response. That's possible (and fairly easy with LM Auth), but it's got little to do with the password/LM Hash database.

    The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.

    Chris -)-----

  • Rainbow Tables , Make your own! (Score:3, Interesting)

    by OneArmedMan ( 606657 ) on Tuesday November 02, 2004 @05:21PM (#10704949)
    A buddy of mine works in Network Security, so for something to do and cause it would help him with his job we made our own rainbow tables. The time it took and disk space is roughly as follows.

    5 average pc's ( all about 2000Mhz or so ) took about 30 days, and generated about 18Gb or tables.

    Now these tables give us about 95%+ hit rate on any LM Hash we , erm "acquire"

    The tables contain all hashes upto 14 Chars length using all letters all numbers and some symbols.

    Just about the only hashes these tables wont hit are the machine generated ones.

    I guess the point is turn *OFF* LM hashes at all cost, and if you absolutely "must" use them, make sure you kept them secure!

    oh and a side note, if you are interested in cracking / brute forcing LM hashes, make sure to run them thru a copy of L0pht Crack or some such to get all the Blank, Pass==Name, Pass==Name-reversed hashes out of the way first.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close