25-GPU cluster cracks every standard Windows password in less than 6 hours
arstechnica.com
arstechnica.com
Taking SHA-1 (which YOU MUST NOT USE for password hashing blah), it only manages 63 billion a second. To try all the passwords for that in the alphanumeric space:
- 10 chars: 35 weeks
- 11 chars: 44 years
- 12 chars: 2,800 years
- 16 chars: 11 times the age of the sun
10 chars for bcrypt: 600,000 years...
http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billio...
Lloyd: What are my chances?
Mary: Not good.
Lloyd: You mean, not good like one out of a hundred?
Mary: I'd say more like one out of a million.
[pause]
Lloyd: So you're telling me there's a chance... YEAH!
- 6 chars: 1.2 seconds
All of which demonstrates the importance of requiring longer passwords. Also, keep in mind that these are maximum times required to crack a password and not the average times.
That in addition to traditional dictionary attacks.
Upshot - it's impressive, but NTLM already known as an vulnerable target.
How many guesses per second do you get in a typical online crack? E.g., a script kiddie trying to guess your cloud server's SSH password?
The particularly persistent IPs get a special iptables rule.
Is it that with user facing services the common user/passwords are so common it's reasonable to just try just the top x most common passwords?
For other sites, I'm honestly not sure how they go about choosing a limit. 20 does seem to be more reasonable, while still being perfectly safe.
http://www.splashdata.com/press/PR121023.htm
There's no reason why you would have a three attempts limit, or five, or ten, and so on. If I get three per account, I'll just use the top three and try again different accounts. If I get three attempts per IP, I'll use many different IPs and do the same.
To remain user friendly, delays are the way to go. E.g. you could have three different delays that add to each other: Account-level, IP-level and global. Increase each with every failed attempt up to 30 seconds of wait time, and add them together. This will slow down brute force attempts to the point where they're useless, while still allowing legitimate users to login (just with a little inconvenience).
As a result, if I failed three attempts with one account, and three one next, etc., my IP-level limit will prohibit me from moving on to other accounts. If I try a lot of passwords on one account, the account-level and IP-level ones will slow me down. And if there's a distributed attack with many IPs, the global delay will reduce the damage the attack can do. All the while legitimate users can still use the service.
I like your approach though though I would redirect them to a appeal process that a human could read, but I'm not aware of the volumes you have to deal with. I would though wonder how this system will adapt come IPV6 times and with that if your not using it then I hope it is disabled as if your ISP/provider suddenly starts processing it or running tests then that latent IPV6 stack doing nothing could suddenly come to life and you probably don't have many firewall or IPtable rules for that in place. But that is a problem many will face over the years comming.
it's a different threat model to hash+email retrieval via sql injection which can lead to all sorts of nastiness involving hijacking email and then other accts
Otherwise regardless of hash crackability, one would be able to do authentication bypass by simply sniffing hashes and replaying them.
It did use the LM hash function to store passwords, which was rather weak, making rainbow table attacks easy.
http://en.wikipedia.org/wiki/LM_hash
For backwards compatible this hash function was commonly in use up to Windows 7 (it was disabled by default in Vista though). There are decent workarounds since NT.
NTLMv1 is also rather easy to crack. NTLMv2 is better but took a long time to be in wide use. Kerberos is strong too and can be used
Long story short, Windows OS prior to Vista maintain weaker hash support for backwards compatibility by default (although you can work around it since NT 4, almost nobody did this). Windows Vista still has support for them if you want to turn it on, but by default it's off. From Windows 7 there is no support for weak system hashes. For Active Directories, MIT's Kerberos (used typically in Unix networked environments since the 80s) replaced NTLM from Windows 2000 on.
3.1 didn't really have passwords to access the system, it did however have screensaver passwords which were either plain text or a very weak hash.
They could also be disabled by simply deleting the line for a .ini file which was bad considering it didn't have the concept of users who could only access certain files.
Gw?Bi2009Isuamtrlpwah#ol,n,&sc. (31 characters)
Create memorable sentences and create a password using the first letter of each word & all the numbers and punctuation. After entering it 10 or so times you'll get used to it pretty quickly.
Guess what? Back in 2009 I saw a uniquely attired man traipsing round local places with a high number of legs, necks and shirt collars.
Big sites are generally good about allowing long/strong passwords. Many mom-n-pop sites are often hit-or-miss.
[1] http://www.nd.edu/~busiforc/handouts/cryptography/cryptograp...
Edit Ultimately security from these types of attack would be with unusual/non-sensical adject/noun, adverb/verb pairs etc -- which your example does reasonably well. Picking a bible verse (for example) would be bad, though.
Assuming the cracker just uses a wordlist containing 200,000 terms and unsophisticated brute force, this thing could crack a 3 word password in a day and a 4 word password in 800 years[1]. It would certainly be an interesting project, but I honestly think this is a safe approach for now.
[1] http://www.wolframalpha.com/input/?i=%28200000**4+%2F+63+bil...
Say we choose one word from the 200,000 and it's a noun. Then we can make assumptions about the next word (eg it's likely a verb) and immediately the number of options for the next word collapses from 200,000 to a subset of some smaller cardinality. In fact we can use our knowledge of common English to restrict the next options down further -- to only verbs that make sense to this particular noun and that agree with the noun's plurality.
So unlike current password brute forcing, where every character is independent of the others -- thus having exponential complexity -- brute forcing a sentence using current NLP methods could be much less expensive. Perhaps a hierarchical method exists that would scale at O(n log n).
Anyway, this is just fun thinking. You're right that current password strategies are a long way away from making this type of cracking worthwhile.
Conversations like this are why I come to hacker news.
It points out "The technique doesn't apply to online attacks, because, among other reasons, most websites limit the number of guesses that can be made for a given account."
Same applies to Windows.
For example the FBI seizes someones computer. This would allow them to brute force without said restriction.
So yes, from an online, or standard entry viewpoint this is a moot point. Also a properly encrypted hard drive using something like truecrypt is still pretty impenetrable regardless.
Buffer overflow the web service, bind a command shell to a port running as the system account (by having the system execute shellcode used in the buffer overflow), netcat to your open port, ftp the SAM (located in the repair directory) to somewhere you can retrieve it, download the file, delete all of the logs, crack the file.
Hard drive encryption would have done nothing to prevent this.
And it's quite common in corporate environments for PGP Desktop HDD encryption to be setup to use the Windows password as the key to accessing the HDD encryption key(s).
For this reason we're advised not to put out laptops in sleep mode when transporting the laptop as someone finding the laptop could do something like the above (remote exploit and then get access). When coming out of hibernation PGP desktop requires the HDD password to be provided so that it isn't in an exploitable state.
On a Linux system usually any user has at least read access to /etc/passwd but only root has /etc/shadow.
This attack would presume that you already have either physical access to the disk or you have already compromised the machine remotely to basically root or admin type level.
Of course being able to get the actual passwords of users would be useful to an attacker because they might be able to use them to elevate from access to one system to potentially other systems where users might well be using the same password.
Not sure how drive encryption with Truecrypt would work in this case. I presume password hashes are stored outside of the encrypted part otherwise every user would have to enter the volume key before they signed in regardless of their access level. Which would mean distributing the volume key widely.
Truecrypt is also vulnerable in the sense that it is often possible to grab the volume key straight out of DRAM if the computer is on or has only recently been switched off.
It is irrational to assume that password database leaks won't continue.
The hashing scheme and salting matters less and less, as the total entropy humans can conveniently recall is quite limited and moore's law keeps marching.
We need a fundamental rethinking of security and identity on the internet, and IMHO the OSS world needs to get there before partisan commercial interestes.
There is no practical reason that website operators need to know that a user typed in the right password, only that they are who they say they are. Anything which is able to prove this (to a satisfactory level) with the least amount of information being stored by the website is good in my books.
Original title: "25-GPU cluster cracks every standard Windows password in <6 hours"
So they could have easily fabbed something like this, or a tuned architecture specifically designed for the purpose.
considering that the entire purpose of NSA in the first place is to provide SIGINT and encrypt or decrypt signals, it's almost a given that they're trying to the best of their ability to crack stuff.
Money buys more commodity hardware faster than the time/money used to develop a chip
It's not hard to make tens, or maybe even hundreds of GPUs beat a specialized chip except for very specific things
And even for something specialized it's probably easier to use an FPGA
Instead, they participate in a program to partner with domestic companies to manufacture their chips: http://trustedfoundryprogram.org/
18,688 AMD Opteron 6274 16-core CPUs
18,688 Nvidia Tesla K20 GPUs
17.59 petaflops
Titan displaced Sequoia (at Lawrence Livermore National Laboratory) from the top spot on Top500. Interestingly enough, Sequoia uses a very different architecture, based on 16-core PowerPC A2 nodes rather than GPUs. Sequoia also has about 1.6PB of memory, while Titan "only" has 1PB.
Both computers have reasonably different use cases. GPUs are great for embarrassingly parallel, non-memory intensive tasks like brute forcing passwords. But all of the rumors about the NSA's massive data analysis needs suggests that they may need a cluster that resembles Sequoia (with fewer cores, but larger caches and available memory) more than Titan.
The combination is exotic enough to be considered non-commodity hardware.
Look at the xkcd password entropy comic
Assuming ~2000 common English words, the number of possible passwords in that format is 2000^4 ~= 2^44. If the calculation is based on a completely random string of letters it is far stronger at 26^30 ~= 2^141 but it's safe to assume people aren't going to memorize a 30 character random password.
It's worth noting that the fairly common 8 character upper/lower case, numbers, and symbols they cracked in 6 hours is more secure than "correcthorsebatterystaple" at 72^8 ~= 2^49.
Wouldn't you have to know in advance that the longer password was only lower case letters?
I was mainly commenting on the format suggested by the comic - 4 all-lower case words. You could throw in capitilzation, but most people are going to follow some pattern such as capitilizing all the words or the first and last, etc. These schemes only add a couple extra bits. Fully random capitilization would greatly increase the strength but make it nearly impossible to remember.
There are a lot of assumptions in these calculations, chief among them already knowing the format of the password. It's somewhat reasonable to ignore though, because not knowing the format of the password is going to add extra complexity more or less evenly across all formats.