Was one of the 14 character passwords
micro$oftsucks
SSD tools crack passwords 100 times faster
Password-cracking tools optimised to work with SSDs have achieved speeds up to 100 times quicker than previously possible. After optimising its rainbow tables of password hashes to make use of SSDs Swiss security firm Objectif Sécurité was able to crack 14-digit WinXP passwords with special characters in just 5.3 seconds. …
-
-
-
Friday 12th March 2010 16:50 GMT Steven Knox
That was rather the point.
The 8GB hash tables were designed to be loaded into RAM because HDDS were too slow. That meant they couldn't be much bigger than 8GB at the time the tool was developed, because even the best machines wouldn't have more than than available, so there would be constant (slow) HDD churn; that was the point of the exercise.
By optimizing their tool, they showed that they could store tables that were 10x as big on an SSD (a HDD would be too slow), load them incrementally into RAM, and still get an exponential performance increase.
In short, slow HDD speeds led to smaller tables led to decreased performance. Faster speeds allow more swapping allows larger tables allows increased performance. The ultimate cause of the bottleneck, and of the solution? HDD speeds.
-
Friday 12th March 2010 15:55 GMT Tom from the States
"Account lockout after x number of tries"
If you use a GPO to lock out accounts after a short number of attempts, as many financial institutions do, then that will put an end to the outside cracking party. Of course, you perhaps just need the SAM file to hack it off-line. In that case, you'd sure as heck better trust your admins.
-
This post has been deleted by its author
-
Monday 15th March 2010 10:22 GMT Joe Montana
Locking out accounts = bad
This cracking is done based on having the password hashes.. However, because of the way windows authentication works you only actually need the hashes and don't need to crack them.
As for a lockout on unsuccessful attempts, you should lock out the source of the attack not the account they're trying.. if you do that, then someone just needs a list of all your usernames and they can cause absolute havoc by intentionally locking out all of your accounts...
-
-
-
Friday 12th March 2010 20:20 GMT Anonymous Coward
Prat.
A little research into Rainbow tables on your behalf would have been nice first.
It doesn't matter *what* your system adds to the retry delay because a Rainbow table gives you the correct password first time. Unless your typing is so damn awful you shouldn't even own a computer you will gain access on the first attempt.
-
-
Friday 12th March 2010 16:49 GMT johno
It's only the LMHash that it work on
Objectif Sécurité was able to crack 14-digit WinXP passwords with special characters in just 5.3 seconds.
Should really say
Objectif Sécurité was able to crack 14-digit LMHash passwords with special characters in just 5.3 seconds.
So its only really cracking two 7 digit passwords in the time and LMHash converts all lower case alpha's to upper case. So thats only 26 alpha nout 52
LMHash is stored by XP for backwards compatability with 95/98 so if you don't need network access to a 95/98 system then you should have LMHash turned off.
Now if it could crack NTLM Hash in that time it would be somthing to worry about.
-
Monday 15th March 2010 02:08 GMT Anonymous Coward
It can.
It can crack NTLM, perhaps not in 5.3 seconds but it's definitely in the minutes range. The time consuming factor with a Rainbow table attack is generating the table in the first place and having fast enough storage to use it quickly. Even with traditional rotating media it's proabably only a matter of a couple of minutes maximum though.
The solution to a Rainbow attack is to lock down physical access to your hardware and manage file/network permissions properly because for a Rainbow attack to succeed the attacker has to have access to your pasword hashes.
-
Monday 15th March 2010 10:22 GMT Joe Montana
Crack NTLM?
NTLM passwords are not very strong either, better than lanman yes but still far weaker than the password encryption used by unix systems.
That said, why bother cracking them at all? windows authentication lets you authenticate using the hash directly without ever having to know what the plaintext password is.
-
Monday 15th March 2010 13:55 GMT A J Stiles
Do what?
"windows authentication lets you authenticate using the hash directly without ever having to know what the plaintext password is" -- then what was the point of hashing the password in the first place?
Somebody, please tell me that the quoted sentence above is not true; because providing the ability to login with the hash alone is even less secure than storing unencrypted passwords.
-
Monday 15th March 2010 14:23 GMT Anonymous Coward
err. OK...it's not true.
Well it sort of is. Loads of systems use the hash to validate passwords rather than reversing them back into cleartext - the missing part of the argument is that hashes are SALTED(e.g. you get a challenge word, ad it to your password locally then hash the answer. Correct hash as calculated at the server side = correct password entered). It's more detailed than that, read up on MD4, MS-Chap v1 and v2, and MD5 while you're at it.
-
-
-
-
-
Friday 12th March 2010 16:50 GMT Colin Guthrie
Salty goodness
@Tom I don't think they are trying to login, but rather taking the encrypted hash of the password and ultimately working out what password would be needed to generate that hash.
If this is the case, they are suggesting the use of a lookup table here (which makes sense as seeking in the lookup table would be faster on SSD). Does that mean that the hashes they are trying to crack are not salted? Salting generally makes lookup tables useless due to the explosion of combinations needed.
-
Friday 12th March 2010 16:50 GMT Cameron Colley
RE: "Account lockout after x number of tries" & Notes
As I understand it this isn't about trying all the passwords against the system -- the "brute force" in the article refers to matching password hashes to tables of known hashes off-line.
The clever part being finding ways to match the password hashes to those in your tables as quickly as possible.
-
Friday 12th March 2010 20:17 GMT Anonymous Coward
I would have thought...
... a beefy CPU could generate and compare password hashes faster than it could read them in from an 80GB file stored on any sort of disc?
Seems to me that to compare the hash against an 8GB table in 5.3 seconds would require a minimum 1510 MB/s throughput. What kind of SSD did they say they were using? Seems more likely to be an array of at least 5 such discs.
At any rate, if someone can get your password hash off your system then you're screwed anyway. Doesn't matter how many locks you had on the door because the burglars have already climbed in through the window(s).
-
Monday 15th March 2010 02:10 GMT Anonymous Coward
I have seen...
...500 Mb/s streaming, constant throughput with ordinary HDD SAN RAIDs (16 disks in RAID10 on a 4 Gbit/s channel) so tripling throughput with SSDs where physical parameters like disc rotation and head movement are removed is not that far out. Gotta put it on a fast channel though. Or RAID it over several channels. But definitely doable, especially in a lab.
-
-
Friday 12th March 2010 20:20 GMT Brian Miller
Please read up on hashes and passwords before posting
Come on, guys, do a little reading before posting.
#1: The password that was "broken" was a broken implementation from the start. The Microsoft "gurus" did a lousy job with the original password "encryption" so it is not that difficult to break it. Read the Wikipedia entry.
#2: Rainbow tables contain a set of precomputed values, so all you have to do is get the hash, and look it up. This comes down to how big your table is, and how fast the information is accessed.
#3: Once the password is cracked, then it is entered *once* for authentication, and authentication is granted.
#4: 80Gb SSD vs 8Gb HDD. This is news that it runs faster?? No, really? A rainbow table an order of magnitude larger can crack a password faster? Wow. So. Amazingly. Brilliant.
-
Monday 15th March 2010 13:55 GMT Anonymous Coward
hashes of hashes
My database knowledge is a bit rusty, but surely with a properly organised dataset, such as a lookup table. Actual readspeed, or size, shouldn't make much difference over a large number of reads, because it needn't do a large number. It should be able to go straight to where the value is expected to be, and try and read it.
-
-
-
Friday 12th March 2010 22:22 GMT Ken Hagan
Re: 300 billion
...is about 100-1000 passwords per CPU clock cycle for any processor in production today. Since the original source (linked from the article) cites this as "worst case" performance, I think we can assume that this is a typo for something RATHER A LOT of orders of magnitude smaller.
-
Monday 15th March 2010 02:10 GMT jonathanb
Yes, they really are that fast
The reason is that all the heavy CPU work is done already in creating the rainbow tables. Essentially you get at the hashed version of the password and look it up in the table to find the password associated with it.
In the same way that you don't have to look at every word in a paper dictionary to find the one you want, you don't have to look at every entry in the rainbow table to find the password you want. They are arranged in such a way that it is easy to find the one you want.
Systems other than Windows defend against rainbow table attacks by adding a "salt" to the password so that there are trillions of different hashed versions of the password that match to the same plaintext version.
-
-
-
Monday 15th March 2010 10:30 GMT Jesse
You have it.
You are right. By taking basic computer principles (mathematics, encryption, CPU/Memory/Hard Disk speeds) and throwing them into an article, they were able to cloud the main details and make this event seem newsworthy. The real magic is that they took most of the CPU intensive work and utilized an 80 Gigabyte dictionary so that the CPU doesn't have much work remaining. At that point, WTF else is there besides some back-and-forth between disk and memory? And then, lo and behold, a faster hard disk gives better overall results. WOW! (sarcasm.)
-
-
Friday 12th March 2010 22:14 GMT Christopher Key.
Am I missing something?
Am I missing something?
With a rainbow table, you precompute hashes for some dictionary of passwords, and then look up the hash of the sought password within that list. Unless you're doing a linear scan through the list of hashes, HD bandwidth shouldn't be relevant. Sure, SSDs may give lookups a couple of orders of magnitude quicker, but I can't see the use in being able to crack a password in 1ms over 100ms.
-
Monday 15th March 2010 02:06 GMT Anonymous Coward
New Database benchmark perhaps
So given this is basicly looking up in a rainbow table to find the predecrypted password. Why dont they just use a database; As that's all there doing in effect, albiet a rather basic table. Though one that would atleast allow for expansion using other forms of encryption per encypted key(jumble of characters).
If you did it like that you could populate the tables from many sources, adding as many forms of encyption as you wished entires.
But that would be realy realy hard and nobody would of ever done anything like that :).
I would also add as a finaly thought for the cheap homebrew people, raptor HD's and other forms of fast HD along with RAID have been around for a while now, certainly more reliable. though for such a task a SSD makes sence given once initialy loaded in the way they are using it then the wear and tear would be next to nothing. Though if I was doing alot of writes I would be looking at the warranty and the like in more detail than the small print on a deal with the devil.
-
Monday 15th March 2010 02:09 GMT Keith T
the distribution of the tools of crime and warfare need to be legally controlled.
I have a simple solution to the security problem.
It is one used by banks, armies, and airforces the world over.
Someone starts marketing a tool specifically designed to damage your equipment, you get a law passed to make that activity illegal and you toss them in jail for a few years.
I have no problem with people doing security research, but as with surface to air missiles and burglary equipment, the distribution of the tools of crime and warfare need to be legally controlled.
Openly encryption cracking tools is openly distributing tools of crime and warfare.
-
Monday 15th March 2010 10:59 GMT Anonymous Coward
Err...
Think of it like a crowbar: I've got a crowbar, I use it to wreck things and leaver things when I'm doing DIY. I leave it locked in my shead because I am fully aware that it can be used to open doors and windows on my house. The breaking and entering of my house would be a specific crime, so no new 'anti-crowbar' law required. It's the same with tools like these, the illigal use of them is illigal it shouldn't be the posession of them (like in Germany? I can't remember off-hand.)
-
Monday 15th March 2010 11:03 GMT Anonymous Cow
Internet fail
Welcome to the internet, thanks for playing. You lost.
I'll assume you're not a complete troll and tell you why:
1. Unenforceability. To stop the dissemination of such knowledge (and it is knowledge that is dangerous here; once one person creates the theory, thousands more can implement it) you need to be able to take down web sites, FTP sites, Torrents, Usenet messages, and so on in any jurisdiction in the world. Possibly hosted on hacked computers, without the owners' knowledge. G'luck. (Oh, and by the way, the bad guys will be exchanging it on USB keys, under the table at the pub.)
2. Dual use. These tools have legitimate applications (password strength checks, lost password recovery). The tools that are out-and-out for criminal purposes (bank login harvesters, botnet tools, etc) are, surprise surprise, criminal. (But, oh wait, they're still out there... makes you wonder, doesn't it?)
3. Full disclosure. It's been found that, without the threat of a publically-available exploit, software companies *will not fix* their bugs. Microsoft has already switched to a more secure password hash (starting from Win2K) and admins who know how to configure their systems can laugh at this attack (as can those running Vista). Without things like l0phtcrack, this wouldn't have happened. We'd all be sitting ducks for those who are already ignoring the law.
-
Monday 15th March 2010 10:17 GMT Stuart Halliday
Is speed everything?
Does it really matter if it was done in 5secs or 50secs?
To do this you had to nick the hard drive in the first place surely?
Not really the sort of program to run on a hacked computer without the user noticing isn't it?
You'd just hook up the drive via a USB enclosure and leave the program running over night?
Or am I missing something?
-
Monday 15th March 2010 10:24 GMT neill miller
300 000 000
it's gotta be 300 000 000 whatever you use US/UK measuring
the cpu is a 4400 dual core, and you need at least a few compares/memory reads for one check, even within the cpu-cache, AFAIK they run 2300MHz
2300x2/300 = 15.3 cycles per check, sounds quick but possible
there's one aspect of SSD though everyone seems to forget: latency!
-
Monday 15th March 2010 10:29 GMT Anonymous Coward
"account lockout"
Let's take it as read that no real logon attempts are involved in this attack.
Now, account lockout as a "security measure" is actually as old as the hills (e.g. VMS had it back in version minus 27, in 1890 or something like that).
But the moment account lockout as a security measure was introduced it was a double edged sword.
If you wanted to target an account for a Denial of Service attack, suddenly it was trivial.
Obviously, today's IT people are mostly young enough to never experienced that kind of thing (or they're mostly old enough to have known it and forgotten).
"isn't the speed of your hard disk usually the bottleneck for most non-trivial problems (i.e. when you have more data than you can fit into memory at once)?"
Quite. There's no news here, and certainly no analysis.
-
Monday 15th March 2010 10:30 GMT Anonymous Coward
not suprising!
this isnt suprising...the process is disk-bound - obviously as they have to pagein/out sections of rainbox table into memory.
they can probably get this speed down to 3 seconds or less by using RAID on the SSD eg 24 SSDs in a RAID - http://www.tomshardware.com/news/samsung-ssd-hdd-raid,7224.html
-
Monday 15th March 2010 10:44 GMT Anonymous Coward
Why not just use RAM?
So, 10x larger rainbow table + SSD with several times faster random read & access than HDD yields a 100x improvement? Surprise, surprise, who would have thought of that!
The 80GB table seems irrelevant - you can just load it into RAM. And not just 80GB - as commenter above mentioned: Dell PowerEdge 900 with 256GB RAM costs $37k over the big pond, if you prefer AMD, the 256GB PE 905 can be yours even cheaper: $34k.
And according to Moore's law, a 512GB machine should cost the same by next autumn...
This is peanuts for a black hat organization...
-
Monday 15th March 2010 10:44 GMT Peter Galbavy
DB's and indexes
Trying to use a traditional database approach and index the hashes would fail big time. Think about how indexes work and the size of the index. If the rainbow tables are organised in any sensible binary-search way already you will not gain anything except creating an index multiple times the size of the data. This is specialised data so should already be organised in a specific way.
As for Keith T and using the "law"... I do hope that was irony. I really do. Else you get a big FAIL sticker on your exercise book.
-
Monday 15th March 2010 11:10 GMT Robert Carnegie
The modern billion
According to http://en.wikipedia.org/wiki/Long_and_short_scales
the British government adopted billion = 10^9 (1 000 000 000) in 1974.
It also indicated the old trillion was a million billion, but I assumed it was a billion billion. I was 8 in 1974 and these numbers have a certain interest at a certain age... if you're weird.
-
-
Monday 15th March 2010 16:43 GMT Keith Oldham
Re : Presumably
I'm not by any stretch any kind of expert about this and I guess you should do some research but for what it's worth ..
Most Unix-like OS now use a randomly-generated 'salt' string (each time password is created/changed ) and use it as part of the hashing function, storing the salt, along with the hash as the users 'credentials'. This essentially forces the cracker to generate another rainbow table set for every permutation generated by the salt - so for a 256-bit salt - that means 2^256 rainbow tables of 80GB or whatever need to be pre-computed OR a specific table needs to be generated for every individual password
Not sure about Windows - I don't have anything to do with it anymore. But I don't think salting was used pre-Vista
Hope this helps
-
-
Monday 15th March 2010 14:43 GMT Graham Bartlett
@Keith T
Call us back when you've figured out how to get your laws to apply to all jurisdictions in which the Internet can be received. I doubt North Korea and Burma will be too cooperative. Oh, and you also need to get local police to enforce that law too, which is a further issue in Russia, Nigeria and other countries with endemic corruption.
And that's just civilian use of it. How's about the Chinese military figuring out ways to crack Pentagon security? Reckon they're going to follow your law?
You might be surprised to find how little control there is over surface-to-air missiles. If you're an organised crime gang in one city, then you might have problems, sure. But if you're an organised crime gang or rebel faction that forms the de-facto government of a region: "of course we can supply those, sir, will you be paying in US dollars or gold...?"
And burglary equipment - oh boy. I can go down to B&Q now and come out with a dozen crowbars, a couple of sledgehammers and a felling axe. More subtly, it's trivially easy to order a lockpick gun online, especially since it's legal in many countries aroune the world.
-
Monday 15th March 2010 14:43 GMT Anonymous Coward
It is a well know fact to those that know it well..
You can get a much quicker lookup for MD5 (not that the article is on about MD5) by using Google (probably the best tool to search for weak password hashes).
1. Loads of web sites use the MD5 hash of the page title as the filename
2. Page names & filenames are indexed by Google
3. Most simple passwords are, somewhere in the world, used as a page title, and so it's hash in searchable in Google.
Simple example, MD5 hash = 6750AEA347AC766AF296266711A6171B
Google search = http://www.google.co.uk/search?hl=en&q=6750AEA347AC766AF296266711A6171B
Hmmm...I'd guess that the password is 'manhattan'
Try it.
PS. This does not apply to salted hashes, and as everybody knows ALWAYS SALT YOUR HASH.
This topic is closed for new posts.
Biting the hand that feeds IT
