Slashdot Mirror
Cheap GPUs Rendering Strong Passwords Useless
StrongGlad writes with a story at ZDNet describing how it's getting easier to use GPU processing against passwords once considered quite strong.
"Take a cheap GPU (like the Radeon HD 5770) and the free GPU-powered password busting tool called 'ighashgpu' and you have yourself a lean, mean password busting machine. How lean and mean? Working against NTLM login passwords, a password of 'fjR8n' can be broken on the CPU in 24 seconds, at a rate of 9.8 million password guesses per second. On the GPU, it takes less than a second at a rate of 3.3 billion passwords per second. Increase the password to 6 characters (pYDbL6), and the CPU takes 1 hour 30 minutes versus only four seconds on the GPU. Go further to 7 characters (fh0GH5h), and the CPU would grind along for 4 days, versus a frankly worrying 17 minutes 30 seconds for the GPU."
And any system worth its salt (crypto-hashing joke) won't allow that many attempts against any external or internal authenticator and will NEVER expose its password hashes.
Seriously, if someone has your password hash, it's game over anyway and it doesn't matter if it takes 2 weeks or 2 months to guess the passwords. And if they don't, then you shouldn't be letting them try several BILLION attempts at guessing a password anyway.
Go further to 7 characters (fh0GH5h), and the CPU would grind along for 4 days, versus a frankly worrying 17 minutes 30 seconds for the GPU."
OK, so go to 15 characters. Using a password generator I can go as far as I like. Using some sort of password bank program, I can store passwords / phrases of any complexity and use copy and paste, thus having only one strong password to remember.
So, what am I missing? (And lets keep it on topic, folks).
Faster! Faster! Faster would be better!
It is well known that if someone gets your hashed password, it is as good as cracked. 17 minutes vs 4 minutes is irrelevant.
On a live system, it is quite another story. You can't just remotely try 3.3 Billion passwords per second.. You'll be locked out after 10 attempts or so.
This is about offline hash cracking, not bruteforcing passwords over a network connection.
Emotions! In your brain!
Is my five letter password more secure if the salt is 15 characters long?
Or am I misunderstanding the nature of the attack and of hashed passwords?
[Fuck Beta]
o0t!
This has to be considering that someone has the password file. Even if a remote system responded immediately, there is lag for the transmission. Also the local host isn't doing the computation, the remote host is, in that case. The GPU or local CPU is only doing the computations if you have the password to compare against.
I don't know if I wrote that clearly. In other words, if I try to log on to an NT server, and type the password "abc" then the remote server is doing the hashing, not my local CPU or GPU.
Hooray, you can crack an NTLM password in like five seconds! Too bad Windows has preferentially used Kerberos since Win2K, which means that pretty much any in-practice Windows network you'd like to hack in to is using a real security scheme.
I mean, really. This article isn't about how much faster a GPU is than a CPU for hash cracking (after all, four days to reverse a hash is still unacceptable, and that's brute forcing it and not using one of the widely available NTLM rainbow tables), it's about how much NTLM sucks and Microsoft should have never contravened the first rule of cryptography and tried to roll their own.
This is really a Windows problem. Windows uses a simple, fast hashing function (I think some version of HMAC). This means that an attacker can churn through many passwords very quickly (apparently billions per second per the article). You should really use a slow hashing function that takes around 0.1 to 1 seconds to calculate one hash on the server. Even a GPU will then take very long! Plus don't forget salt (different per user) against rainbow table attacks, plus key strengthening. Something like bcrypt is pretty good, but scrypt is probably even better as it does not only require a lot of CPU time but also significant memory (making dedicated hardware crackers much more expensive).
A 6-7 letter password only using letters and numbers is NOT strong.
It would be trivial to cover it with rainbow tables and have near realtime cracking even without GPUs.
_Not weak_ would be 10 letter+, with a salt. Would make brute forcing not really that easy anymore...
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
If you're a hacker, my bet is you have at least 10 more friends with recent gaming rigs... And guess what? The problem is embarrassingly parallelizable. 4.8 days for a 9 char password(worst case, btw)
8-character passwords were strong enough for Unix thirty years ago, but that was a long time ago in Moore's Law cycles; I've got wristwatches faster than that PDP-11. It's annoying how many systems still seem to use them.
For systems that do passwords interactively, you're not going to get the same brute force speed, but you're still exposed to automated attacks - using a CAPTCHA in addition to the password can help prevent them.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
3m are going to introduce a larger post-it-note
The title of the article is extremely misleading.
I don't really care that someone can break short passwords generated via MD4. MD4 is very broken. NTLM is essentially 1992-era technology that was later picked up by Microsoft, who now deprecates its use.
When a GPU can break 15-character AES256 keys, then I'll start to worry about the security of my 24-character key.
Am I part of the core demographic for Swedish Fish?
Even for Slashdot, this is a little pathetic: the link is to a ZDNet article, which regurgitates a PCPro article, which in turn regurgitates a blog post by the guy who actually ran the tests, Vijay Devakumar. And here's Ivan Golubev, who wrote the cracking tool.
Still, ZDNet's advertisers thank you for the hits!
Solution: Make a stronger password.
This is about offline hash cracking, not bruteforcing passwords over a network connection.
Assume someone gets access to a hash table of passwords and cracks many of the passwords. The system itself doesn't matter but the fact users tend to re-use passwords does, especially with seemingly secure and hard to remember random character strings. Assume the hacker knows enough of the users to have a clue about what other systems they access. With a list of user ids and passwords from the first system, they will likely find a combination that works on the other system and this can be done over the network because of the small number.
Your shameless plug is correct, but for one problem:
When you use a fingerprint sensor, the traditional attack methods (brute forcing, social engineering, etc) still work. But you also add a new attack method, by generating a fake fingerprint from that coffee cup you threw into the trash that morning.
Needless to say, increasing the possible attack vectors decreases security, rather than increasing it.
"City hall" in German is "Rathaus" Kinda explains a few things......
It doesn't work like you think it does.
Basically, most modern password protection techniques work like this: they take a password, say "my nice password" and transform it into a hash, say :"uq10ajg901a0##". Now only the hash is stored on the system. There is no way to go from the hash to the password. Classical hash functions are MD4, MD5 and SHA1. NTLM users MD4. Linux mostly uses MD5. There are added niceties likes salt, etc. You can look these up if you want.
When users enter their password, they are hashed again, and the *hash* are compared, not the passwords. If you enter the right password, no matter whether this is a nice word or sentence or jumbled letters, the system lets you in.
Crackers simply assume that the *hash* is available. It is in fact very easy to get it if you have access to the console, both for Linux or Windows. They then generate any and all combination of letters, signs, symbols and so on as input as potential password, they compute their hash, and they compare it to the hashes they know. If there is a match, bingo, they have found the password.
So the upshot is it doesn't really matter what the input password look like as long as the crackers can generate it and compute their hash. If the crackers know that you have used only letters, however, they can cut down dramatically on the numbers passwords they have to generate and save time.
So in some sense you are right but not for the reason you mention.
Hope this helps.
New hashing algorithm that takes a minute to compute? Some hashing algorithms got turned down specifically for being too fast, and too easy to use in a bruteforcing attempt. [citation needed]
LuLz(sec)
It is well known that if someone gets your hashed password, it is as good as cracked. 17 minutes vs 4 minutes is irrelevant.
Bullshit. It is well known by people who don't know what they're talking about, which includes TFA.
Do you seriously think that in the age of bitcoin we can't make a hash function that is arbitrarily difficult?
Use an adaptive cryptographic hash function: bcrypt, PBKDF2 or scrypt. The key feature is a tunable stretch factor that basically sets the number of rounds of hashing. Set that factor (by means of a simple timing loop) to require 1 second of CPU time (or GPU time or whatever) to hash.
Now the simplest 8 character A-Z password will take an expected 3,311 years to break. You'll obviously want a safety margin, and will expect them to have more computing power a few years down the road. But you can tune the stretch factor to ensure that a reasonably strong password is perfectly good against offline attacks.
This article spells it out:
http://www.baekdal.com/tips/password-security-usability
Too bad most sites are too stupid to allow a long enough password. I'll take a 16-character pass-phrase with all lower case + whitespace over a hard to remember 8 character one anyday.
It is well known that if someone gets your hashed password, it is as good as cracked.
Say what now? My passwords are 32 characters long, contain upper case lower case numbers and symbols, and are easy to remember. That creates a search space of 1.86 x 10^65 possible passwords. Have fun with your measly 3.3x10^9 passwords per second. The article considers a 7 character password to be secure. It isn't. Every additional character increases the search space by a factor of 95. Length matters.
If you want to really spoil a hypothetical hash-cracker's day(and, depending on the keyboards you routinely deal with, often yours as well), you can take advantage of the fact that some systems(recent NT derivatives among them) will accept the assorted unicode characters not accessible on the keyboard of your language area.
It isn't fun to type; but "♯╪˧¾ᾥ▓►ﻸ" is relatively unlikely to fall easily. (Thanks Slashcode, still handling that Unicode, I see...)
Same shit with all the scare on rainbow tables. I remember the hype of "It can crack any password in seconds!" Then I found out it meant any LM password, which has some real limitations on it (14 characters total max, as two 7 character hashes, no upper and lower case). Ahh, not so impressive then.
Same shit with NTLM. Worlds better than LM, but not current. Wake me when it is a threat vs NTLMv2, which is what Vista and 7 use exclusively unless you manually change security policy (and XP and 2000 support it).
Then there's the fact that they are talking about short passwords. Security comes in length and it goes up drastically with each character. They are crowing on about how easy 7 character passwords are. Ok, fine, try 14 then. It isn't like if 7 takes 18 minutes 14 takes 38 minutes. It is more like if 7 takes 18 minutes 14 takes years.
Also to make a long, secure, password doesn't have to be that hard. Just take a phrase and modify it a bit. Say you decide the phrase "There can only be one," should be your password. Do something like "Th3r3 can only be #1!" Fairly easy to remember, yet you have to exhaust a massive space for a brute force attack.
Finally, all this is an attack against the hashes. While we want hashes to be strong, let's face it they are a last line of defense. This is a situation where someone has already gotten in, gotten high privileges, and stolen that list. This has no relevance to dealing with breaking in to a random system remotely.
Pretty much this is just fear mongering. Yes, you need to use longer passwords these days. So do so. However a short password really isn't as bad as they make it seem. The risk they are talking about here is only if someone happens to get the hash file from a system with NTLM passwords stored that you use a short password on. Given that the only system that qualifies for that for most people is their home desktop, if they get it the hacker has owned your system already (you have to have admin to get the SAM file) so it doesn't matter.
Parent is a case-study in What's Wrong With The New Slashdot. In a proper world (or, if you prefer, in the Elder Days) the AC parent would have AT LEAST cruised up to +3 Informative in as many heartbeats. As it is, this nifty site/tool he's pointed us to will languish in obscurity.
And in case you're wondering at my 'get off my lawn', my REAL Slashdot UID is in the low 800Ks, but contains a special character, so I haven't been able to log in to this Brave New Slashdot for over a month.
SHA512 takes less time to calculate than MD5. You'd be making brute force easier event though you are adding more bits!
bcrypt, scrypt, and pbkdf2 allow you to adjust the of iterations necessary to calculate a password. If you want you can crank up scrypt where it takes several seconds of pegging your server cpu to authenticate a password. A GPU could still accelerate that, and if it was a thousand times faster than a CPU (it's not) it would take a year to walk through 3 billion guesses instead of doing it in a second.
“Common sense is not so common.” — Voltaire
Doesn't matter how strong a password is, xkcd have it covered.
I've got a fever and the only prescription is more COBOL.
Really, more systems should make use of the various encrypted key exchange schemes. They fairly strongly guarantee that you can only get one guess at the password per attempted login, even if you manage to intercept the communication beween server and client. (Obviously there's not a lot they can do about brute force attacks if you manage to acquire the information the server uses to verify the passwords, though.)
It's not that simple. Cryptography is an asymmetric game: you always have to assume the attacker has orders of magnitude more computing resources than the target. Cryptography works because we can (usually) find problems that get exponentially harder and harder to crack. For instance, let's say you just want to encrypt something. A block cipher with a 64-bit key is just on the edge of being brute-forcible today. But, as a general rule, you could use a block cipher with a 128-bit key and it should only be half as fast as the 64-bit cipher (note I said this is a general rule, there are number of factors that influence speed). A 128-bit block cipher is 2^64 times more difficult to crack than a 64-bit block cipher. So, the target can make something 2^64 times more difficult to crack by just doing twice the work.
Your proposed solution just grows linearly, not exponentially. If you iterate SHA-1 10,000 times instead of just 5,000 you're also doing twice the work, but this time you've only made your password twice as difficult to crack. If you can suddenly start doing twice the work you did before, you have to assume the attackers can as well.
Yes, iterating hash functions buys us more time, but this is a game that targets can't win. Plus, you're ignoring all of the problems associated with moving to higher iteration counts. Probably first and foremost is interoperability. There's a massive application base out there that just uses MD5 or SHA1 with little to no iteration. It's not easy for software like Windows to change. I think it wasn't until Vista that Microsoft stopped storing a LAN Manager hash of users' passwords, which made then trivial to break. That's been known to be bad for a long, long time. Plus, in most web-based applications its not the client that does the hash operation, its the server. While your new Core i5 processor could probably easily handle bumping up the iteration count by an order of magnitude or so, Google's Gmail servers probably can't.
Longer, more complicated passwords would be more effective than increasing iteration counts, but people are bad at generating and remembering long passwords. So, the only long term solution seems to be moving to stronger forms of authentication, like smart cards or using devices like smart phones as one-time password devices.
except dictionary attacks aren't combining words in the dictionary in to phrases.
There are 171,476 words in the english language, according to the count in the oxford dictionary (source: http://oxforddictionaries.com/page/93)...probably many more in reality. If your phrase is 4 words long, using just the words in the dictionary, that's 8.65x10^20. If your cracker is going at 1 million guesses per second, then it's taking your "ultra-quick" dictionary attack is going to take about 27 and a half million years.
Are there 128 bits of entropy in the image produced by fingerprint readers? With only ~100 million fingerprints on record, there are a handful of known false positive identifications. Wikipedia knows of four cases of misidentification, so a low estimate would be an "identical" (for current technology) rate of 4/100,000,000, or 2^-24. So you get 24 bits, that's a four character mixed-case alphanumeric password. (IOW, 2345 is a 13 bit password, and twothreefourfive is a 13 bit password with some security by obscurity, not a 128 bit password.)
Bottom line: Want a strong password that you can type anywhere? Make it 12 mixed case letters, numbers and at least one punctuation mark. Based on the times claimed in the article, that should take 35,000 current GPU-cracker-years.
Some years ago, back when I was still using Microsoft tools for programming (I think it was about 1999), Microsoft put on some seminars in my area, which they did from time to time. There was one seminar on System Security that some friends and I attended. The speaker was some bigwig in security at Microsoft, but I don't remember his name now.
One of the first things he said was "It's impossible to have too much security, right?" The audience almost unanimously agreed. He said "Wrong!"
He said, "In NT, you can set up a password policy that requires every user to have a password of at least 10 characters, containing at least one upper and one lower case letter, at least one number, at least one non-alpha character, and require them to change it every week. Is that a secure password scheme?"
Again, the audience agreed with him.
He said "Wrong! It is a bad password scheme. As soon as you set that up, what your people will do, is write their password down on a post-it note and stick it to their monitor. This is a ritual they will repeat every week when they change their password."
A 7 character alphanumeric password has an entropy of ~41 bits, a 7 word passphrase (using his 225 000 possible words) has an entropy of ~124, the equivalent of a 21 character alphanumeric password. Care to revise the 28 second estimate?
Analogies don't equal equalities, they are merely somewhat analogous.
What I've always wondered about password cracking is that if you have sufficient access on either a linux or a windows system, you have sufficient access to change the login routine.
Just an example, change :
if (password_ok(user, password)) {
mail_to_oelewapperke(user, password) **
(original code)
** yes I know smtp mail is a total disaster to use for this. It's often blocked, unreliable, or worse : monitored. There are better, quicker protocols that pass through every firewall I've ever met in the field (even the ones *I* configure generally don't block at least 3 protocols you could use for this).
But given that you can download the shadow file, you can replace the pam_unix.so (after which even ssh will be sending it's passwords to you, so it's nice and general way to do this). On windows you can "stack" the GINA (which conveniently sends both local logins and rdesktop logins. Handy).
It used to be the case that people checked the integrity of .so's on their system, especially these VERY critical ones, but those days are long over. At least windows contains a (small) landmine you could step into when trying this. And of course, you have to prepare for this (though these days it's pathetic, there are basically 2 pam_unix.so versions : 32bit and 64bit, otherwise they're interchangeable over distributions. On windows, we're talking 3-4 different versions of the dll's and 2 different ways to install them).
Given that doing this gives you access to past *and* future passwords ... Real fun to see tell a sysadmin "hey I hacked your system", only to have them reinstall and tighten the firewall and replace *all* software and ... and .... and then tell them "hey I hacked your system again" 5 minutes after they've invested a week of time fixing their system.