Slashdot Mirror


Swiss Researchers Exploit Windows Password Flaw

Bueller_007 writes "CNET is carrying an article about a new (albeit simplistic) method used to hack alphanumeric Windows passwords in a matter of seconds, rather than minutes. To blame is a 'weakness in Microsoft's method of encoding passwords.' According to the authors, the same method, when used on Mac OS X, Unix and Linux boxes, however, could require either 4,096 times more memory or 4,096 times longer." A few more details: Mister.de writes "As an example we have implemented an attack on MS-Windows password hashes. Using 1.4GB of data (two CD-ROMs) we can crack 99.9% of all alphanumerical passwords hashes (2 37 ) in 13.6 seconds whereas it takes 101 seconds with the current approach using distinguished points. We show that the gain could be even much higher depending on the parameters used. This was found at the Cryptography and Security Laboratory of the Swiss Federal Institute of Technology in Lausanne (EPFL)."

30 of 519 comments (clear)

  1. Performance increase by levik · · Score: 5, Insightful
    THis sort of performance increase is only useful for Mission Impossible type movie spies... I mean come on - who can't wait 100 seconds???

    People are really running out of interesting stuff to "research", aren't they...

    --
    Ñ'
    1. Re:Performance increase by Marx_Mrvelous · · Score: 5, Insightful

      You obviously aren't a computer scientist (or a computer hacker). What they got was a power of ten increase (roughly). This is a significant improvement because it is not simply incremental. Look at it this way:
      Let's say it usually took 200 days to crack a password. A company could enforce a 90-day (3 month) requirement to change passwords, and a brute force technique would have roughly a 1-in-2 chance of getting a password in any given 90-day period. Now they increased it by a factor of 10.
      Now it takes 20 days to crack a password. If the company want to keep the same level of password security, users would have to change their passwords every 7 days!

      This is a pretty big issue.

      --

      Moderation: Put your hand inside the puppet head!
    2. Re:Performance increase by MisterFancypants · · Score: 4, Insightful
      Yeah but their power of 10 increase isn't globally applicable to many types of encryption breaking, it exists due to a flaw in Microsoft's specific implementation, so really the original poster is right, this isn't big news of any sort.

      I can't imagine it would have made the front page at all if not for the usual "See how insecure Micro$oft is!" Slashdot biases.

    3. Re:Performance increase by Rogerborg · · Score: 2, Insightful

      You can "let's say" all you want, but it's 100 seconds down to 13.6 seconds. How about explaining the real world significance of that? Seems to me to be like quibbling over how many times we can nuke the world into glass. After the first time, it's just about dick size.

      --
      If you were blocking sigs, you wouldn't have to read this.
  2. DMCA?! by neosake · · Score: 2, Insightful

    Good thing they're in Switzerland, or they'd get hit with a nice DMCA Lawsuit :D

    --
    "When a ball dreams, it dreams it's a frisbee"
  3. I don't understand by Trelane,+the+Squire · · Score: 5, Insightful
    While an attacker would need administrator rights to a system to grab the file that contains the password hashes, the file is still valuable, said David Dittrich, a senior security researcher at University of Washington.
    if a hacker had administrator rights, wouldn't it already be game over? On the other hand, a 20 gb hack isn't extremely portable
    1. Re:I don't understand by Quietust · · Score: 4, Insightful
      if a hacker had administrator rights, wouldn't it already be game over? On the other hand, a 20 gb hack isn't extremely portable
      Not quite - admin rights would only give access to whatever was on that particular machine (and stuff on the network), while the passwords of everyone who used that system would be considerably more valuable.
      --
      * Q
      P.S. If you don't get this note, let me know and I'll write you another.
    2. Re:I don't understand by Xner · · Score: 2, Insightful
      You obviously didn't read the story or failed to picture this properly. It requires a huge chunck of memory. Furthermore, the data in it's dictionary has to come from some where. Very doubtful you'll be able to sneak several gig worth of data onto a machine, and load it into memory, for it to be used as a remote exploit.

      Sorry to interrupt your tirade here ... there's no need to get the tables onto the target machine and run the cracker remotely, you just have to sneak the password hash back onto your local machine and run it locally. Did you even bother to click on the first link? It would have been amazingly obvious.

      --
      Pathman, Free (as in GPL) 3D Pac Man
  4. Is this really news worthy? by mjmalone · · Score: 3, Insightful

    This is hardly a news. These weaknesses have all been known for years, and the use of dictionary attacks against passwords is very common.

    Bruce Schneier talks about all of these attacks and weaknesses in his book "Applied Cryptography" which was published years ago.

  5. Re:Scary stuff... by perly-king-69 · · Score: 2, Insightful

    Biometric logons and encrypted /home directories?

    --

    --
    This sig is inoffensive.

  6. 13.6 seconds vs. 15.8 hours by isn't+my+name · · Score: 1, Insightful

    Either way that is too fast. Looks like another good argument for non-alphanumeric characters in your passwords.

  7. So? by ioErr · · Score: 5, Insightful

    13.6 seconds or 101 seconds doesn't make much difference, now does it? The real problem is still getting administrator access to the target computer in the first place.

  8. With distributed computing, why bother? by jeeves99 · · Score: 5, Insightful

    Cracking becomes easier if you have access to a distributed network. Parse the table into managable chunks and throw it out to 100 computers. While the time taken to crack the password might not scale down in a linear fashion [ie: time/(N computers)], it will most definately drop the crack time down to less than an hour for those computers with 12bit salts (4906*.6min= 41 hr, 41hr/100comps= 25 minutes).

    Even if the 12 bit salt for mac/linux/etc was increased in size, a scale up in the number of computers used would defeat this added protection. The trend in the comp world seems to be more connectivity between large numbers of computers. All it takes is one disgruntled folding@Home grad student out at stanford to break even the most stringent password.

    It seems that increasing the size of the salt would prevent the average script kiddie from breaking your password, but does nothing to alleviate the threat distributed computing presents. So what other options are there?

  9. Re:This is why... by gazbo · · Score: 2, Insightful
    What he means, and has quite a valid (if unpopular) point with is that because of Windows' huge dominance, the majority of all hack attempts, and the vast majority of all viruses are directed at Windows. Because people consider Linux to be too obscure to be worth spending their time attacking, it rarely succumbs to such attacks.

    And before you start yammering about Many eyes/shallow bugs or whatever, I shall use my new favorite example: the sobig worm. In order to get infected with this, a user must receive an email, save the attachment, unzip it, then execute the file contained within.

    *speechless*

  10. Re:Time for OSX, UNIX, Linux by A+Commentor · · Score: 3, Insightful
    So you are not multiplying the proper time. So without any precalucated data, it takes 1m 41 secs, having this precalculated info drops it down to 13 sec.

    Now to keep it close to 13 secs, you would need 4096x more data - 1.4G x 4096 = ~5.7 Terabytes.

    If you don't have any data, and have 4096 more combinations, you need to take 4096 x 1m41s ~= 4.8 days. Not quite as bad but it still looks like like we need a few more bits for the password salt...

    We should just make it a 64-bit salt and not have to worry about it until Quantum computers are viable..

    --

    Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com

  11. Re:Gee... by ncc74656 · · Score: 5, Insightful
    I always thought there was something wrong with Microsofts password "encryption." Now it's confirmed.

    Why bother cracking NT (and Win2K/XP) passwords when you can just overwrite them? Boot from this floppy and you can change any local password (including the administrator). It's been useful on more than one occasion at work...when somebody quits or is fired, I can go in and retrieve everything in just a few minutes.

    That they're nearly as trivial to crack is somewhat disturbing...but given the ready availability of the password changer, it doesn't make Windows significantly less secure than it already is (hell, it can't get much less secure).

    --
    20 January 2017: the End of an Error.
  12. Re:No salt by Anonymous+Struct · · Score: 5, Insightful
    To their debit, most WinDesktops that I'm aware of end up as glorified single-user machines, and that user is also.... Admin. Finally build a decent security model, and then customers ignore it.

    I think the customers only ignore it because they've been bred on Win9x, which sort of casually asked if you felt like typing in a password, but didn't really care one way or the other if you actually did. You can't train people that passwords don't matter for 7 years and then expect them to start caring about security when you finally decide to implement it. So now we have a sea of internet users who don't know or care one whit about security all because they've been taught from the very beginning that all they ever have to do is plug it in, turn it on, and start browsing.

  13. Only 4096 more time on Unix ? by chrysalis · · Score: 4, Insightful

    I strongly disagree. Maybe this 4096 times applies to the traditional single DES crypt. But execept for some rare compatibilities issues with old systems or for dumb people that create Apache .htpasswd files with it, nobody uses single DES any more for years.

    Passwords hashed with MD5 and Blowfish don't have the 8 character limitation. There are still some people who like to assign users passwords like "*9_p7Z9ox" even though their system doesn't use single DES any more. This is just plenty stupid. Not only it's a hell to remember for the end user, but it's damn fast to brute force when hashes are precomputed as described in this article.

    A normal password like a real sentence (ex: "I'd like to have sex with Sandra") is not only way more easy to remember, it's also orders of magnitudes harder to brute force.

    --
    {{.sig}}
  14. Re:Only works with NTMLv1, NTLM v2 not effected. by Anonymous Coward · · Score: 1, Insightful

    "This is reason enough to migrate to Windows XP."

    You spelled "The is reason enough to find a complete replacement for Windows." incorrectly.

    What kind of guarantee that Win XP won't turn out to have very similiar flaws to Win 9X and in 5 yrs people would be saying "This is reason enough to migrate to Windows 2008"? I don't have those guarantees. In face, based of Microsofts history, I assume Win XP has the same sort of fundamental flaws as Win 9X, they are just not found yet. In the future, this will be a reason to pay MS more money so you can "fix" the problem.

  15. Re:This is why... by schon · · Score: 4, Insightful

    Because people consider Linux to be too obscure to be worth spending their time attacking, it rarely succumbs to such attacks.

    This is just plain false. If it were true, then there would be MUCH more attacks against Apache than IIS - but the reverse is true.

    Also, even if this assertion were true, can you provide references for it (as I asked in my previous post)? Let's see some posts from Linux users who think that they're immune from hack attempts because they run Linux and not windows.

    And before you start yammering about Many eyes/shallow bugs or whatever, I shall use my new favorite example: the sobig worm.

    First, a worm is not a hack attempt - it's malware (along with viruses.)

    Second, malware such as this has little to do with obscurity - it has to do with a mindset that ignores basic security practices (namely segregation of resources.)

  16. Security as an Upgrade Path by msgmonkey · · Score: 2, Insightful

    With regards to upgrading, I've come to the conclusion that even though MS says they want to improve security in their products having flaws is a great way to force people to upgrade.

    I'ill give NT4 as an example which is EOL'd. You're a company who has managed to get your NT4 server rock solid. A new security flaw comes out and since NT4 is EOL'd MS says no security patch for you, upgrade to Win2K.

    Of course if you was a complete conspiracy theorist you could say even MS would leak holes in their old products.

  17. Re:This is why... by gazbo · · Score: 2, Insightful
    I think you missed the point of me bringing up the sobig worm. What I was trying to get across is that if all things were equal (Windows and Linux had equal shares of the desktop, and they both had the same demographics of users) then you would see a huge increase in the number of "security breaches". The reason I used sobig in particular is that you can claim Linux has all the security in the world, but it can't help with someone who will take an unexpected attachment, process it, then run it.

    It doesn't have to be a hack to be a security problem, and I was giving one undeniable (surely nobody would be stubborn enough to deny it?) example of where the only reason Linux is not affected is because it is not as widely used.

  18. Re:This is why... by nolife · · Score: 4, Insightful

    I see your points to some extent but consider Apache was been by far the most popular web server for at least the last 8 years running on various platforms. Security is in design and not proportional to popularity. Hack ATTEMPTS maybe be higher with popularity but those attempts are useless until you find the hole.

    --
    Bad boys rape our young girls but Violet gives willingly.
  19. Re:This is why... by enomar · · Score: 5, Insightful

    I read the parent post as, "Because MS uses security through obscurity, many people think that Linux distros are inherently more secure than MS." I think he meant that security through obscurity doesn't work very well.

    Building a lock that cannot be picked by a blind man is a lot easier (and less effective in the real world) than building a lock that cannot be picked by someone with the blueprints.

    --

    :wq
  20. Why this doesn't matter AT ALL by psamuels · · Score: 2, Insightful

    This isn't a security problem.

    Windows password hashes (both the LanManager hash described here and the newer NT hash) are never sent "in the clear" over a network, or accessible to non-admins.

    Why? Because they are plaintext-equivalent. Most NT network protocols treat the hash itself as a shared secret and do not make any attempt to verify that you know the actual password.

    Yes, that's right. You already don't need to know the user's unencrypted password - except possibly for changing it (I can't remember offhand whether the various password-change calls require proof of knowledge of the old password - but I don't think they do either). Once an attacker gets the hashes out of your SAM, the game is already up, even if he can't decrypt them.

    Given this fact, I sometimes wonder why Microsoft even bothered to try making NTLM a secure hash. BASE64 would have done pretty much the same job.

    Move along, nothing to see here. Your passwords are just as secure, or as insecure, as they ever were.

    --
    "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
  21. Re:No salt by MattCohn.com · · Score: 2, Insightful

    Then all I need to DoS the machine is this hammer I've got in my back pocket. DDoS? Two hammers. The moral of the story? Give someone physical access to the box and it's their box. No amount of security can prevent that.

  22. Re:No salt by mentin · · Score: 2, Insightful
    The attack described in the article is dictionary attack, i.e. you take lots of [alphanumeric in the article] passwords, hash them, and compare your password hash with the huge database of hashes.

    Switching to MD5 without salt would not stop this attack, since you don't have to do MD5 -> String convertion, just lots of String -> MD5 hash conversions, and these are very fast.

    --
    MSDOS: 20+ years without remote hole in the default install
  23. Re:WTF is it with you security guys! by DaCool42 · · Score: 3, Insightful

    You grab the password hash off the network with a sniffer. Then you can work at cracking it for as long as you like.

    --

    ----
    All of whose base are belong to the what-now?
  24. Re:This is why... by Shippy · · Score: 2, Insightful

    I read the parent post as, "Because MS uses security through obscurity, many people think that Linux distros are inherently more secure than MS." I think he meant that security through obscurity doesn't work very well.

    Security through obscurity works just fine as long as that's not your only defense. Security practices should always be done in-depth, with multiple tools to protect you. Let's say I have my gold in a safe in my house. Rather than just put my safe in the garage (where it's not obscured at all), I'm going to hide it somewhere obscure to make it harder for you to find it. Sure, you'll probably eventually find it, but combine the time to find it with the time to crack the safe and you've added more time for the police to show up. Of course, this assumes that I've already taken other measures (alarm system, etc) to complete the in-depth experience. :)

    --
    -Shippy
  25. Re:What the hell is up with the md5_crypt code?? by Tom7 · · Score: 2, Insightful

    Yeah, I understand the general intention of the code. I don't think there's anything wrong with trying to make the hashing code slower, in fact, that's probably a good idea.

    What does worry me is:

    - The whole algorithm is extremely ad-hoc. Since it serves an important cryptographic function, it should use cryptography carefully, and this doesn't. I have faith in MD5's practical ability to mask the author's missteps, but I'm not a genius cryptographer myself so I don't know what's possible. I do think that knowing the input has a special form would be an aid to cryptanalysis of the algorithm.

    - The code itself is bizarre and (IMO) buggy, which leads me to believe that nobody ever audited it. It seems likely that I was the first person to look at it carefully (7 years later when I ported it to SML)--that's really scary since it plays such a vital role in the security of the system.