Was one of the 14 character passwords
micro$oftsucks
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. …
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.
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
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...
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.
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.
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.
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.
"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.
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.
@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.
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.
... 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).
...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.
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.
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.
...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.
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.
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.)
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.
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.
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.
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.)
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.
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?