Less good against non-NTLM passwords ... from my comment last time:
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:
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.
The average time to crack will just be half of the maximum, so it's not a big difference (compared to order of magnitude errors, anyway). Still good to point out, though.
I would guess that the letter frequency, digram and trigram frequencies etc are quite skewed compared to random. Just by taking that into account, you would crack an average password much faster than you suggest by trying the most likely passwords first. There are plenty of already cracked passwords to draw statistics from.
That in addition to traditional dictionary attacks.
That's a good idea if the password was human-generated. With computer-generated random passwords, like gH8r;2CpyyK!a, you might want to optimize differently.
NTLM hashes are stored in Active Directory servers as one round of unsalted MD4. It's plain MD4. Not many people know this and I only point it out as it's important to understand that when talking about how many cracks per second they are getting.
Impressive as the numbers are, it's worth remembering that this is an "offline crack", going against a stolen list of encrypted passwords. If they can steal your database of encrypted passwords, you've got a problem no matter how strong the passwords are.
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?
I suppose it's a bit different from a user facing login, but does anyone know why these limits tend to be set so low? I've locked myself out of plenty of things, and so have plenty of people I know. It seems like setting the limit to 20 would be just as effective in blocking brute force attacks without being user unfriendly.
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?
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.
So far it hasn't been a problem (fingers crossed). I have a couple ways into the server in case I get myself banned. Also, it's my personal server, so the only user that would complain is me :)
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.
I remember using the nice fingerprint reader upon my old IBM laptop once, worked well until you changed your password and then if you had not updated the one in finger print encypted libary you got some impressive automation. Usualy it would automate yoru password once you scanned your finger. Now with the power of a computer you could scan your finger once and watch as the wonderful system tried the wrong password as fast as it could repeat upon itself. Was fun restoring my blackberry from backup after the 10 failed attempts in nanoseconds.
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.
Not much implementation actually. Fail2ban does all the hard work, and then if I get too many emails reporting the same IP I go in and manually permaban the offending IP (doesn't happen often).
These hash functions are made to be fast to hash :P
Check out the NIST competition, they picked the fastest hash that can be calculated with special hardware :)
People who want real offline password security should use slow hash functions (and passphrases of course).
it's my understanding that NTLM hashes are sent over the wire...? therefore any machine on the local network could intercept this hash via network-level attacks such as ARP poisoning, WiFi attacks, etc. Then the cracking box would quite happily and easily brute force the entire 8 char keyspace and reveal the pass.
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
I remember back when I was doing a network engineering course the guys could crack a windows password in minutes offline, simple matter of grabbing the database from the machine. I think once you have the machine offline unless you encrypt the data your pretty screwed regardless..
When was this? I know older windows versions stored passwords in plain text... I can't remember when they switched to hashed passwords but I think it was around XP or Vista
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.
You might be thinking of a very old version of Windows, like 3.1 vintage.
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.
Guess what? Back in 2009, I started using a method to remember long passwords with a huge # of letters, numbers, & special characters.
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.
or you can literally write the whole sentence, which is even more secure and you don't have to remember any special rules, just the sentence itself. Of course it's more typing:
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.
136 characters or 14 Gigayears to crack. Wow today I learnt that there's such a thing as a Gigayear.
I use a password manager, and I have a unique password per site. I generally try to use an MD5 hash resulting from a "ps waux | md5" at the time of registration. I've encountered sites that rejected this due to lack of upper characters (oracle.com, which then allowed me to use "Abc123"), having no special characters, being too long (often forcing me to down-size to 16 or 8 chars). The worst are sites that silently truncate long passwords (I'm guessing due to code errors), so your password is invalid the second you register and must immediately proceed with a password reset.
Big sites are generally good about allowing long/strong passwords. Many mom-n-pop sites are often hit-or-miss.
Well, to be fair, 14 Gigayears in terms of an attack geared towards a totally different case. I wonder if we can optimize an attack on sentence passwords using hidden markov modeling, or other natural language processing methods. The entropy at the character level decreases if we assume the password is an english sentence [1], and my gut feeling is that we can apply this same thinking at the word level as well (this may very well have been demonstrated already in research).
I thought about that, but presumably since so very few people use sentence based passwords, crackers don't optimize for this use case yet. Regardless it's quite a long sentence and that should afford some additional protection against this kind of attack, i can imagine 3 or 4 word sentences being defeated by this kind of technique, 30 words seems a lot more difficult
This is purely a thought experiment at this point, but it would actually be a pretty interesting project. I wonder if it's true that longer sentences would be more secure -- or perhaps entropy decreases with larger inputs that give more data to analyze. In the cipher world this would be true, but for O(1) hashes, I'm curious how this could be tested.
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.
The problem is that you have no hints about what is correct or not because presumably a one way hash is being used, so even if you get the first 29 words right, you don't know that.
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.
I know we've pretty much made our points by now, but my argument is that brute forcing at this level might be more feasible than what you suggest here (if we assume the sentence is correctly using a particular language).
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.
I'm not sure there is much significance to this article.
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."
I think what they're referring to is having access to the physicial harddisk. In linux terms it would equate to having a copy of the /etc/passwd file.
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.
I've grabbed the SAM file from remote IIS servers in my younger years and cracked the passwords locally.
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.
> 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.
Technically you want /etc/shadow as that is where the actual hashes are stored.
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.
Offline attacks matter. The last few years have seen a continuous stream of high profile account database leaks. There are now some 1 billion known real user selected passwords that are readily downloaded from any of a number of shady sites.
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.
I saw a talk on Mozilla Persona [0] the other day from one of the devs. I like the idea of these decentralised authentication systems. I was (and still am a fan of) OpenId too.
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.
Thinking about it some more. Is the only practical exploit of this the case where a rogue sysadmin wants to figure out user passwords (without resetting the password and therefore alerting the user)?
For comparison, a couple weeks ago Oak Ridge National Laboratory's Titan computer topped the Top500 list for fastest supercomputer in the world (although that title is a bit misleading). Here's the specs on Titan:
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.
Put your tin foil hats away. This doesn't "crack" NTLM, it brute forces at a very high rate. The NSA has more money to spend, but are similarly limited by the hardware available at any given point.
The NSA has access to their own chip fabrication facilities. I do not know if they own their own plant, or just have secure fab space at some other company's plant.
So they could have easily fabbed something like this, or a tuned architecture specifically designed for the purpose.
It's very probable that they have and if so, it's almost certain that it would involve specialized hardware implementations (ASIC, FPGA, whatever) rather than commodity graphics hardware which is burdened with expensive and useless stuff like onboard memory and would be power inefficient
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.
I wouldn't call a big cluster of commodity hardware simply commodity hardware because then many of the top supercomputers of the world are commodity hardware.
The combination is exotic enough to be considered non-commodity hardware.
I know for practical purposes this doesn't seem like that big of a deal, but you have to understand that 8 chars of mixed case, numbers, and symbols is still a gigantic key space. That this can be done so quickly on commodity hardware is pretty impressive.
From what I remember of the comic, the point was not the length of the password. The entropy was calculated based on 4 possible words.
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.
I'm not sure which part you're asking about. I'm assuming it's that "correcthorsebatterystaple" is only lower case.
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.
I'm not sure what you're disagreeing with here. Are you saying that 9-characters translates to a significantly larger than key space than 8 characters? Well, yeah -- of course. My point is that this is still a noteworthy feat.
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...