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!
My passwords(for important things like the disk encryption one or my work email) are at least 13~15 characters long, including Upper-Lower cases, numbers and special characters, and no dictionary words. Now I did my part, so how about the people on the server side ?
The answer to this kind of attack is to hash passwords using hash functions that take a bit more time to compute.
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!
From TFA: "It gets worse. Throw in a nine-character, mixed-case random password, and while a CPU would take a mind-numbing 43 years to crack this, the GPU would be done in 48 days."
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.
Shameless plug follows...
Seriously, once you're free from having to remember your own passwords, you can make them as long and complex as you like, and you can use a different *truly random* password for every login, so one compromise won't lead to others. There are freeware workalikes, but none that match 1P's feature set (syncing, browser auto-fill/change plugins, etc). Highly recommended.
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 only storage technology had kept up with GPUs! Instead of being limited to 8 character passwords because of stringent storage limitations, we could use entire passphrases that might be both fairly easy to remember and far more challenging for password guessing. But I guess we'll have to wait for some sort of technological breakthrough...
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Yeah, brute forcing NTLM login passwords. What's next, brute forcing your bank's 4 digit pin code? Please, give us a break. From wikipedia on NTLM: http://en.wikipedia.org/wiki/NTLM
Microsoft no longer recommends using NTLM in applications:
Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms (RFC1321) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in RFC1320 and FIPS46-2. Therefore, applications are generally advised not to use NTLM.
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)
Comment removed based on user account deletion
Just make the hashing algorithm slower. For example, let's say you use md5 to hash the passwords. Hash the password 1000 times with md5 instead of just once. This will increase the time it takes to crack the passwords by a factor of around 1000.
Since GPUs are rendering traditional passwords insecure and obsolete, why not go with a broader usage of smart cards? Also, build in mechanisms to deny IP addresses from machines that are attempting to use brute force. I do it with OpenBSD's PF. After so many failed attempts over a period of time, the IP gets blacklisted. After 24 hours, the blacklist gets purged.
Self-explanatory.
http://www.wimp.com/strongpasswords/
The NSA guy who needs to spend 43 cpu years across a farm of, say, 1000 servers in order
to get a password in half a month probably has to write an application to his boss.
The NSA guy who needs to spend 48 cpu days on the same farm in order to get a password
in a little more than an hour can probably just go ahead.
(And, yes, servers in farms often do have GPUs in order to expose this kind of specialized
performance.)
Comment removed based on user account deletion
So the TFA proves that password cracking is exponential in the length of the password, and that GPUs cut down on the rather large constant in front of the exponent. This still does not eliminate the fact that each digit added increases the cracking time exponentially. In other words, use a longer password. Of course, NTLM is a farce since it only hashes 8 byte chunks, so you can't up the cracking time by more than X^8. The moral of the story here is that GPUs are faster than CPUs (for some specialized applications), yet you can still overwhelm them using a longer password. The other moral is that NTLM is an utter failure, but we all knew that.
If anyone really cared enough, they could build a single-purpose circuit to calculate hashes and compare with the hash file. With enough money invested, you could easily beat any GPU by a couple orders of magnitude. That still doesn't make this news worth discussing as the other side can up the ante by adding to the password length again (among many other things already mentioned such as salts).
Government is not reason; it is not eloquent; it is force. Like fire, it is a dangerous servant and a fearful master.
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
it seems to me, if your password is random, mixed-case alphanumeric, and fairly long, there is an added layer of security against a brute-force hash attack like this. that being that the incorrect hashes will just be jumbled strings of letters and numbers... but the correct password will be, as well. how would such an attack differentiate the valid password from the invalid in this situation?
-It is by will alone I set my mind in motion.
Does anyone really use less than ten character passwords anymore?
Your bank. My bank. The nuclear reactor down the street. All sorts of folks.
Faster! Faster! Faster would be better!
Sure, IF we're talking about remote logins.
What about, say, a stolen laptop, how exactly will you enforce "1min/try" there...?
No sig today...
3m are going to introduce a larger post-it-note
The problem with NTLM has been known for some time, but it is not just NTLM. It is in fact any challenge response protocol. Check this slide deck presented at the IETF in 2005: http://www.huitema.net/talks/ietf63-security.ppt. The punch line is simple: don't rely on challenge response protocols! If the attacker can see both the challenge and the hash, and if the password can be remembered by the user, it will probably be cracked.
Try reading the post you are replying to...
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?
What kind of incompetent fool would still use such a pathetically weak password hashing scheme?
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.
It's the power of modern GPUs that's worrying you? Really? What you should be worried about is the security software you're using that uses md5 for password hashes. Use a more expensive algorithm - bcrypt, or better yet, scrypt. And if your software or OS uses md5 for passwords in a situation that's vulnerable to local brute force hacking... upgrade!
If you lose your laptop, you've got bigger things to worry about. There're much better ways of getting at whatever information the person is after.
hashes don't normally "go over the wire". They don't for web logins, they don't for remote logins. They reside in a file on the host. If you copy that hash file from machine to machine by insecure means that's your problem, not something a good admin does. Encrypted file copy is a nice feature of the ssh/sftp/scp suite. E
Right, so it will take 10 black hats a work week to crack one password. Given the ratio of black hats to usernames, I wouldn't worry too much unless you are person of relative interest.
Also, they have to get the password file (or equivalent) in the first place.
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.
That's neat. Using Upper & lower cases with a few punctuation characters, about 15 characters are enough to give a big computation time.
One thing I have started to do is to use pass phrases. For example, "Green peppers allow access." gives a massive cracking array time of 39.98 thousand trillion trillion centuries. Even just "Green peppers" gives 38.90 centuries.
Another thing I tend to do is splice 3-4 mini phrases around a concept, e.g. the "Red Hot Chilli Peppers" group:
RHCP (the bands initials)
b4nd ('band' with the A transformed to a 4)
Californication (name of an album/single)
so you have: "RHCPb4nd Californication" which gives 9.38 hundred billion trillion centuries and covers at least one uppercase, lowercase, digit and punctuation character.
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.
Cracking one password may be enough for a larger attack even if the target user is not particularly high priority. So, maybe the hackers gain access to the shadow file of some other system, and correctly surmise that a low-level employee at the target company uses the same password for their work account as for whatever other system was compromised, and now they have access to the target company's internal LAN.
The real answer, IMO, is to start moving toward cryptographic authentication methods, and remove the problem of passwords altogether.
Palm trees and 8
A more informative link should be included, like:
http://www.openbsd.org/papers/bcrypt-paper.ps
so nerds not in the know can understand how silly the article is. NT hashes are a joke and other than pointing out how bad all the non-bcrypt ones are. It is not all that useful to work on GPU brute forcing for poorly designed systems... (other than to make a point or to aid in exploitation of them.)
You can use shorter passwords if the hash algorithm is sound. dictionary attacks will work regardless but once you are into using brute force your password could be short if it takes a long enough amount of time to cover the domain. bcrypt "scales" to as slow as needed ( I feel odd using "scales" in this way... ) one could make it so expensive that searching the space for short passwords would be too costly.
Democracy Now! - uncensored, anti-establishment news
Because the crypted passwords never get grabbed for cracking offline.
Never all in all of computer security history.
All those stupid passworded files you download from rapidshare/megaupload/etc. can be brute force opened without having to jump through the maker's stupid loop holes.
Yes, it does make the assumption that you've been able to remove a copy of the encrypted password list and analyse it locally.
If you brute force a service or UNIX daemon over a network then it's going to lock you out of that account for good after maybe 5 attempts, or it might just lock for 20 minutes or so meaning that it's going to take you an incredibly long time to be successful. Besides which, any security or sysadmin guy worth his salary is going to have set up syslogging of invalid access attempts to somewhere where he gets an alarm indication when this stuff is happening.
It's also worth mentioning that if you're going to pull out a local copy of the encrypted passwords, even if it's possible to do so (Windows guys?), the mimimum account access you will need is root on a Linux or UNIX system (well, modern UNIXes anyway).
So, yes, it's a security concern but unless you know the root password, or someone with the root password, of little practical value in the real world.
Gentoo Linux - another day, another USE flag.
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.
Phrases are not as secure as one might expect, it is not equivalent to a password several dozen characters in length. In some ways it is like substituting words for letters, a seven word password is only more secure than a seven character password in the sense that there are more words in a person's vocabulary than they are letters in the alphabet. Perhaps a "practical" improvement but not even approaching "pretty much unbreakable", even with substitution. In short, all the things that make passphrases easier to remember works in favor of the cracker. Frequency and correlation are a factor. In something analogous to a dictionary attack, given a phrase of a certain number of characters one might try famous quotes, passages, etc that match that length.
FWIW, phrases were often used to test the configuration of German enigma encryption machines during WW2. The British at Bletchley Park had some success in discovering unknown phrases and that was with 1940s technology. One German operator was discovered to be using the German equivalent to "mary had a little lamb". Better yet, he used that phrase every morning despite his training.
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.
All the break-in attempts I've ever seen happening to one of our systems has only tried running through a list of users / passwords that are, bluntly, pretty dam' obvious choices. That none of them has ever succeeded on any of our user accounts tells you nothing about the strength of the individuals' passwords (policy set by the CIO's IQ/memory abiliity: 6 or more letters+numbers)
All it tells you is that the amateurs who run these scripts get a high enough hit-rate from rest of the internet to keep them happy - and not wanting to try anything harder. My personal belief is that if we did ever get hacked, the source would be internal or through information leaked by a user from social engineering, not from some script kiddie with a room full of GPUs, throwing off enough heat to make the cops think they've got a marijuana farm in the building.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
... 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. ...
That sounds like you are using some words. If so the search space is smaller than you believe. Any time you can use the phrase "easy to remember" you no longer can use the mathematics of random permutations. Think in terms of tokens not characters, with a token being a word or a character. A token that is a word may be more secure since there are more words in a vocabulary than letters in an alphabet but a five character word is far less secure than 5 random characters.
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.
This problem is trivial to defend against. Simply employ key stretching. You can make it take as long as you want.
NTLM hashes are calculated on the host and submitted across the wire to a server in response to a request for authorization.
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)
But your friends have to stop playing games for 4.8 days. Good luck convincing them of that because you want to crack a single password. ;-)
You are assuming a lot of knowledge about the password scheme for an attack. This may apply when dealing with secrets of national security, this does not apply to random systems on the Internet. Yes, a pass phrase could potentially be weakened by some cryptanalysis against the person. Knowing something about their vocabulary, the movies and literature they like, dates, addresses, and other things significant to them, etc could be used to load a system to search a smaller space.
However that isn't the kind of research someone is going to do. You and your data are not worth that kind of money. Hackers are not going to spend tons of time researching a target like that.
Also you have to remember that you slow down tries a lot if the logic gets more complex. These brute forcers are fast because they are simple. It is "Pick next valid combo, hash it, compare to hash, if it doesn't match, repeat." If you start having tends of thousands of cycles of logic to generate your guess, that slows shit down a ton.
Always be aware of the threat you are trying to protect against. The measures the government needs to go to to protect nuclear secrets are not the same ones you need to protect your lolcats photos.
Think of it in terms of physical security. Think how flimsy your door lock is, how easily a battering ram could take it out. Think how easily your windows are broken, and so on. Should you secure all that? Should you live in an underground bunker, guarded by marines? No, because you've nothing worth that kind of effort to protect. You are sensible about what protection you need.
Nowdays, once your hashed password is exposed (e.g. someone posts a database dump of your favourite forum somewhere), it is unlikely that the system where it was stored was not completely compromised. It is unlikely that the attacker could not grab or modify all personal data / other information that was stored on the system. He can gain entry to the system using your account by modifying your password, so 0 security left there to compromise by recovering the plaintext password.
...
The only benefit he or someone else could gain from cracking your password would be to try it elsewhere in case you are stupid enough to still use the same password for several different accounts... So: don't do that, use long random passwords stored in a safe place (in your password-protected browser if you must) and you might as well stop worrying about the next generation of rainbow tables or 100 times faster GPUs etc.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Right, so it will take 10 black hats a work week to crack one password. Given the ratio of black hats to usernames, I wouldn't worry too much unless you are person of relative interest.
Wait, aren't we looking at this wrong? Yes, if the black hats only had one password to crack, it would take this long. But if they've gained access to the entire password hashfile, they have many passwords to crack, and they're just trying to get lucky. Each time they pull a hash from a rainbow table, they have the equivalent of [number of users] lottery tickets. Successfully cracking one password would give them access to the machine, and no matter what level of privilege that account has, gaining any kind of access is a huge step.
I guess what I'm saying is, from the perspective of one person who wants to protect their individual account, yeah, you might not worry too much. But if you're the guy in charge of protecting the server itself -- and by extension, the security of every account on that server -- then worrying seems justified.
Breakfast served all day!
Wouldn't changing to SHA-512 from MD5 make this a moot point ? What if the stored hash was the MD5 hash of the SHA-512 hash of the actual password ? Or, the Md5 of the SHA-512 of the MD5 and so on.......
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
Do you seriously think that in the age of bitcoin we can't make a hash function that is arbitrarily difficult?
All right, strong enough with the spurious bitcoin references. We don't care about your silly toy project, no matter how many times you choose to mention it.
Unless some bone-head forgot to limit access to the password field in LDAP to compare-only, or forgot to turn on encryption on the LDAP transport. ;)
This could be more of an issue for something like a zip file, 7-zip file, truecrypt volume, etc. Something where the encrypted data is local, and protected by a password. Think of a stolen DVD or USB hard drive which you had put stuff on.
In such a case, the attacker can hook the device up to their own computer, which will NOT enforce any artificial delays. In such a case, the only thing protecting your data would be the complexity of the password itself, and of the algorithm from which an encryption key is derived from the password.
Doesn't matter how strong a password is, xkcd have it covered.
I've got a fever and the only prescription is more COBOL.
You assume the only use of passwords is for "online" systems where an artificial delay can be imposed by the server.
What about encrypted files? How are you going to impose a delay on someone trying to decrypt the file on their own computer, potentially using different software than what you used (e.g. the software you used might impose a delay, but maybe they have written their own implementation, or modified an open-source version, to skip the delay and continue full speed ahead)?
Isn't this why we're supposed to move all these transactions over https? (Except for the NTLM token, you probably shouldn't allow those to fly over the WAN under any circumstance.)
Don't blame me, I voted for Baltar.
I can break a password of 'fjR8n' in less time than the GPU.
fjR8n
see?
All this is talking about NTLM password hashes, the algorithms used by modern unix systems are a lot tougher and even with modern GPUs, still very slow to crack...
More importantly, NTLM password hashes are plaintext equivalent, so you can use them without having to crack them at all (google for pass the hash), so cracking them is only for amusement value anyway.
So the problem is not so much GPUs, its more to do with windows systems having extremely weak methods of storing passwords.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I remember reading a write-up about that back when the gawker media password file leak happened. One of the schemes, I think it might have been the LanMan hash, effectively reduced all passwords of any length to a sequence of like 7 or 8 character passwords, because it hashed each section of the password separately - e.g. it would hash the first 7 characters, and store that, then hash the second 7 characters.
So, to find the full password, you just lookup one 7 character password in the rainbow table, then the next 7 characters, etc. Since each individual lookup takes like 1/1000 of a second on a modern computer, you could instantly crack any length password 'hashed' with that scheme.
Do you seriously think that in the age of bitcoin ...
I think there's a whole bunch of people with cheap GPU's out there in the age of Bitcoin.
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
'You can't really prevent these [brute force] attacks: nothing prevents an attacker to just try all possible keys and look if the database decrypts. But what we can do (and KeePass does) is to make it harder: by adding a constant work factor to the key initialization, we can make them as hard as we want."
To protect its database (of passwords), the program actually performs N rounds of AES encryption, with N being a large number of your choice, chosen so that these rounds take "a lot of time", say 1 second. This way, the attacker will only test 1 password per second.
Does this make sense ?
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.)
Nobody is trying to brute force a remote login--your account would be locked after a few failed attempts anyways. This is only a valid approach if you've somehow got your hands on the hash file. More and more we see people like sony having plaintext passwords or Gizmodo have unhashed (reversible encryption) passwords. The sites that have your password properly stored as a hash are not the ones getting hacked in the first place.
I though the use of delay loops went away with computer games of the 80's. Besides, as soon as a faster computer comes out, the old algorithm is useless for security, and the new algorithm is so slow that it's useless on the old computers. Same problem that led to the move from DES to salted DES to MD5 to SHA512 to... You're chasing your tail with key stretching.
So it takes a minute to log in anywhere? That'll go down well with people...
No sig today...
Quit pushing the solutions on the users. You don't need to use longer passwords to make it harder to reverse password hashes, all you need to do is salt the passwords and use iterative hashing (key stretching) to make each guess take longer. In a well designed system, it should take 200 days to brute force passwords for 1000 users, assuming all users had three character lowercase alphabetic passwords. This is base on tuning the number of hash iterations so that a guess takes 1 second to verify.
Taking the information into the article into account, there is a new wrinkle. The application will be using the CPU to compute hashes an attacker might use a GPU based approach. The numbers for the article show the GPU to be about 1500 times as fast as a CPU, getting the horrible passwords from the previous paragraph in about three hours. However, those were absolutely horrible passwords. By tweaking the password policy so that passwords must be five characters long (still no requirement for mixed case or non-alphas), we could still see passwords take 1 second to be verified in the application and the 1/1500th of a second for the GPU based attack would still require 91 days to complete brute forcing the entire database. Of course, nothing will help the users with passwords that are at the top of the dictionary. The best part about iterative hashing is that if we have the same discussion twenty years from now, we simply tweak the number of hash iterations and we get exactly the same results.
What fascinates me about this scenario is how many collisions can be found during this brute-force process?
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.
NTLM hashes (and most others) are sent over the wire in a number of circumstances.
The whole point of password hashes is to have something more secure than a raw password to transmit over the wire. What do you think is sent over the wire if not a password hash?
- Michael T. Babcock (Yes, I blog)
Thank you for pointing this out. I'm wondering why people are upset about NTLM hashes being broken; any good user disables the legacy storage of them.
My password is tYidsasaf770 and my IP is 198.81.129.125 - can someone try this GPU thingie on me? I want to be secure as possible. Thanks...
Humor from a Genetically Molested Mind
Thats why i dont use a password..or at the very least...
So the combination is... one, two, three, four, five? That's the stupidest combination I've ever heard in my life! The kind of thing an idiot would have on his luggage!
------------
Sase
"It's the opposite of that."
your big cracking times are misleading, because you haven't factored in dictionary attacks. 'green peppers allow access' would probably be ultra-quick to crack.
Wealth is the gift that keeps on giving.
And don't forget all the people who set up rigs specifically optimized for computing lots of hashes quickly to mine bitcoins *looks around furtively*...
Information theory is life. The rest is just the KL divergence.
so this means i may finally have a quick way to get back into that encrypted file I forgot the password for? I should have known that the 32 character password was a bad idea.
I've decided to Diversify my Holdings. I've divided my cash between my left and right pockets, instead of all in one.
I don't need a Windows password using a weak algorithm, I have an encrypted partition with Truecrypt that ask a password at boot just after BIOS, mine is 24 characters, I am wondering what a GPU could do...
"Science will win because it works." - Stephen Hawking
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.
I use Kanji for my password!
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Yes, it scales linearly. But if you set a 1-second minimum on hashing, and a GPU normally does 3.3 billion/second, then you've done 3.3 billion times the work. Not twice the work. Plus a brute force attempt would not know the number of rounds, and so would have to try, say, everything from 1 round to 9.9 billion rounds, just to be reasonable. So requiring a second or two of hashing has potentially required billions of times more work to generate the hash, and requires billions of times more work to break (which already takes relatively a long time), assuming no shortcuts.
Perhaps it's reasonable to do this much work when generating each password. How many new users/minute do you expect? If you add users at that rate, there are bigger scaling problems.
Stronger forms of authentication should be used in addition to strengthening passwords, since passwords will likely still be one factor used. Even two-factor authentication employing a password plus a "stronger" form can become meaningless if the password can be brute forced and the other factor overcome with social engineering or simple theft.
That's too hard to remember. I use "password" for my password.
You don't just hash a password when you you store a new password. You also have to hash the password every time a user logs in. Now I agree you could certainly increase the iteration count on passwords, but one full second of computation on a busy server isn't going to fly. Companies have pushed back over far less. It has taken a long time to get where we are today when it comes to using TLS for login pages, and that's far less than one second of computation. Far fewer companies continue to use TLS once you get off the login page, even though the symmetric encryption operations that take place after the initial key establishment are even less computationally intensive.
I was just the example of twice the work to show how much easier it is to make brute-forcing a key infeasible versus brute-forcing a password. Yes, I'm sure you can do more than twice the work. But you're not going to get away with doing 3 billion clock cycles. I think you'd have a hard time getting people to deploy enough iterations to block brute-forcing attacks. And even if you do, it would be short-term fix. Bumping up the key length of an encryption algorithm can extend security a long time. From a practical perspective, AES-256 should work indefinitely, as long as someone doesn't break the algorithm itself. There's probably not enough energy in the universe to brute-force a 256-bit key, and quantum computers don't help that much. Bumping up the iteration count by a factor of 50 or so (any more and I think you'd have a hard time getting people to deploy it) basically just gets you the same thing as another character in the password. That's not enough to block these attacks. And by the time you'd actually get that deployed password crackers would be even more powerful. And since you can't get companies to change crypto algorithms and protocols constantly, you'd basically be stuck with that for 5-10 years.
You're not going to close hole with higher iteration counts alone.
I use sentences for all of my passwords. I have in effect a 20+ character password which is just as easy to remember as a word. I throw in a number in replace of a word or letter and bam - i have an alphanumeric 20+ character password which is extremely easy to remember.
Whats the harm in yelling 'Computer, end program!'? You could be living in Star Trek! Go on.. give it a try.
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...)
Not useless, but do the math. A printable ASCII character space can be typed almost anywhere, and gives you about 6.5 bits of variability per character. The cases described in the FUD of the article are all assuming limits on the length of passwords shorter than 8 characters, but they don't hide the fact that lengthening the password (or in fact, just allowing longer passwords) gives pretty good protection rather swiftly even with a fairly limited character space. At 6 bits per character, 2 more characters means about a factor of 2k in time to guess, 4 more adds a factor of 4 million. Based on the numbers in the summary, a 12-character password will take that GPU well over 8 millennia. That's not a meaningful number, but it is well past any rational threshold of being easy to crack.
At 6 bits per character, 2 more characters means about a factor of 2k in time to guess, 4 more adds a factor of 4 million. Based on the numbers in the summary, a 12-character password will take that GPU well over 8 millennia. That's not a meaningful number, but it is well past any rational threshold of being easy to crack.
Bad math. My factors were too low. 2 more characters from a 64-character space (as implied by the examples) would multiple the guessing difficulty by 4096, 4 more by 16M, and a 12-character password would occupy the claimed GPU for 35ky.
NTLM hashes do NOT go over the wire. You use the hash to encrypt a "well known" key and sent THAT across the wire. The remote server then does the same thing and compares the results.
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.
And what about Rainbow tables? Those things can break weak password even faster than a GPU, by virtue of being precomputed. And available for download.
And slightly OT, but is there any actual GP-GPU software out there that isn't for black hats?
Newest Photoshop and Folding at home GPU client, CUDA optimized.
Two that come to mind quickly.
-AI
For me, it is far better to grasp the Universe as it really is than to persist in delusion
hunter2
[...] memorizing a handful of 12-character passwords is no harder, in a practical sense, than memorizing a handful of 10-digit phone numbers.
Sensational alarmist crap at its best.
I don't disagree at all with your overall point, but as a practical matter here you are wrong. As it turns out, most human brains have a threshold at 7 items. Below that the difficulty of remembering a sequence of items grows linearly with a very low slope (i.e. remembering 7 numbers is only slighly harder than remembering 6) but past that it gets hard parabolically, so much so that most people will find mental ways to break up any series longer than 7 into parts. You don't really remember a 10-digit (NANP format ) phone number, you remember the 3-digit area code and the 7-digit local number, which most people probably break into 3+4 . If you are remembering a 12-character password your brain will break it up into at least 2 pieces, both of which should be rather random (unlike phone numbers) and containing more than digits. However you do it, the same number of 12-character passwords will be harder to remember than 10-digit numbers.
"fjR8n" is your idea of a secure pword? Allow me to introduce you to the following chars: "!@#$%^&*()_+-={}[]"
Does Win* allow those in pwords?
"Tongue tied and twisted, just an Earth bound misfit
Note that the article is referring to NTLMv1 which uses 56 bit DES and, as illustrated by the article, that is easily broken. However, the article conveniently fails to mention that as of Vista and Windows 2008, default security policy requires NTLMv2 which uses 128 bit RC4. That is a totally different crypto scheme. Despite the fact that the protocol for exchanging authentication tokens (NTLMSSP) has been around since early Windows NT days, it doesn't matter - cryptographically 128 bit RC4 is fairly secure. At least the difference between 128 bit RC4 and the 256 bit AES used by Kerberos is not the weak link (and as of today Windows domains still default to allowing 128 bit AES to be negotiated anyway).
Also, note that NTLM authentication is absolutely not obsolete. Kerberos clients require access to domain controllers. Kerberos is very sensitive about the name a client uses to authenticate with a service and it is very sensitive about DNS. It requires a lot of manipulation of principal names and key files. Time must be synchronized on all three machines involved in a Kerberos authentication. Stale tickets may need to be purged. If any of these things are not right, it can be non-trivial to track down the problem. NTLM does not have any of these issues. NTLM is much more robust than Kerberos. It's just less efficient and it lacks features like delegation. A "pass through Kerberos" mechanism is being developed to replace NTLM that would resolve some of these issues (the main one being that clients would not be required to access domain controllers), but I suspect it will still be quite a while before it actually does and it's not clear that it will solve all of the aforementioned issues anyway.
Actually for the NTLM hash mentioned in the article, the maximum effective password length is 7 characters.
That's why the NTLM hash was replaced 15 years with NTLMv2 which doesn't have that weakness. And the NTLM hash has been turned off since Windows Vista.
As usual, when discussions of cryptography happen on Slashdot, a lot of nonsense gets bandied about. Let's clear some of it up:
Bcrypt is "adaptive" in a sense, in that you can specify (to a certain extent) the number of key setup rounds to be used in the algorithm. But there are some assumptions that many people are making in this discussion that simply aren't true. Let's take care of the assumptions first:
(A) This discussion is about brute-forcing passwords via the Web.
No, it is not. Because of various factors (one of which I bring up below), it would make no sense if this were about web-based attacks. For one thing, there is no way in hell a GPU utility could be doing web-based attacks that fast, no matter how fast it was itself.
(B) bcrypt is an advantage when faced with attempted brute-forcing over the web.
This is simply false. When doing web-based authentication, it is the server that does the hashing. The only advantage that bcrypt might have is that computing the hash takes time... but since it's happening on your own server, that is not an advantage. You could simply introduce a small delay before your hash is computed, and you will get exactly the same effect. Better, in fact, because of a serious issue with bcrypt, which I will explain below. But to be clear, this discussion is about breaking passwords assuming that someone has your database.
(C) Both MD5 and SHA1 are broken, to some degree.
This is nonsense. Certain weaknesses have been found, but the odds against those particular weaknesses (such as the probability of a collision with MD5) being used in a real-world exploit are astronomical.
(D) Certain hashing algorithms are vulnerable to rainbow tables.
No... ALL hashing algorithms, no matter how complex, or how much time they take, are vulnerable to rainbow tables, by their very nature. There is nothing in the world that can change that, except:
(E) Salts are completely unnecessary if you use the right hashing algorithm.
Utter nonsense. Salts are the only thing that can save you from rainbow tables. Some people have pointed to bcrypt, saying that it doesn't use salts, but in fact it does. It's just that unlike most other schemes, it stores the salt in the same database entry as the hashed password.
Now here are some things that seem to be contrary to popular opinion about bcrypt:
(1) You can specify how much time the algorithm takes to hash your password.
No... all you can do is set a "work factor" (N) to be used by bcrypt. The number of key setup rounds will then be 2^N. Not only is that NOT a fine-grained "tuning" mechanism, it has nothing directly to do with time. Given the same work factor, a supercomputer (or GPU) will still compute the hash a hell of a lot faster than a standard CPU doing the same thing. What you are adjusting is difficulty, not time, and and settings that can only be powers of 2 do not exactly constitute "fine-tuning".
(2) bcrypt will help prevent web-based brute-forcing.
No (see above). If your only concern is a web-based attack, then introducing a simple delay before your existing hash function will give you exactly the same protection... over the web. In fact, it gives you better protection in a sense. You see, using bcrypt with one "work factor" setting is NOT compatible with bcrypt at a different work factor. If for any reason you wanted to ratchet up your security by increasing bcrypt's work factor, all your existing passwords would have to be re-entered by their users, because there is no way to go from one hash to the other... the new hash has to be computed from scratch.
Which means that, for all practical purposes, bcrypt is not really "tunable" at all. Once you have users with established passwords, changing bcrypt's "work factor" will require each of those passwords to be re-computed. Which means the end user will have to manually
There's been a raging debate internally as to whether or not we should change to hashed passwords. (for historical reasons, passwords aren't hashed now)
I've pushed for hashing repeatedly, but it's always been downsided by the fact that users are often technological cave-dwellers who have trouble turning their computer ON, let alone not being able to get their password from a support staff.
However, I'm not sure it matters so much, anyway. There are a number of techniques (such as hash tables) that make hashing much less usable, this GPU attack only exacerbates an already bad situation.
I'm of the opinion that anything less than 2 factor authentication is broken now or soon, anyway. I'm in favor of a random, cell phone text tied to the password, myself, except that texts are sometimes delayed. It works like a one-time password and can't meaningfully be broken since the time window of opportunity is far less than the password timeout for trying again.
Done right, this can't even be used to cause a DDOS because, if it's tied to IP addresses, the cracker would have to work 24x7 for a few hundred thousand years to make the window of opportunity, or, use a few hundred thousand IP addresses for a year to do the same in a year.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The "nobody but us geniuses can make or use strong passwords" problem has been over and done with for a long time. And it turns out that anyone who advocates for requiring non-alphabetic keystrokes is simply ignorant, genius or not.
Just use diceware. Roll five D6 dice, look up the resulting base six number in the diceware dictionary, and write it down. There's your first short, memorable word. Repeat three times for login credentials and the like, seven times for "really strong" cryptographic pass phrases. When calculating password search space, it is easily found that length is everything: Increasing the symbol set increases the base, increasing the length increases the exponent. So your diceware pass phrases lose nothing of value if they are all lower case with no spaces and no "exotic" keystrokes - they just become much easier to remember.
http://world.std.com/~reinhold/diceware.html
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.
Actually, the only solution is to do away with passwords as the ONLY 'lock' on protected systems. Multi-factor authentication is the only way to go. Sure there can be a password in there (something the user KNOWS), but cracking that gets you nowhere in itself. You'll also need the access card, token or whatever the user HAS and the finger, eye or whatever biometric component that represents what the user IS.
So, with such systems you can't just steal a hash file and crack that. You'll also need to physically access the user and get his code key and his finger... As 99% of all computer crime is executed remotely, this will be efficient to stop intruders. Even social engineering is mostly done remotely over the phone. Having to get close physically means a greatly increased risk and thus chance of capture. In other words - it will be pretty efficient at keeping unwanted visitors out. This is probably why most online banks use something like this (two factors minimum) as their access security.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
If the password protects access to a system, it needs to be secure only so long as it is the password in use for that system. If it becomes less secure, switch to a different one (or a different system like two factor authentication). If it protects data (like an encrypted volume) then you need to decide how long that data needs to be secure for.
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.
What an utterly irrelevant comment, obviously you can't GPU-accelerate a remote login, that's got nothing to do with the issue here.
Fact is data breaches do happen (see Sony) and if you can suddenly brute force a password 300x faster than before that is a very big deal. 10 GPU equipped desktops can now do the work of 3,000 CPU based desktops...
Which means that, for all practical purposes, bcrypt is not really "tunable" at all. Once you have users with established passwords, changing bcrypt's "work factor" will require each of those passwords to be re-computed. Which means the end user will have to manually enter it again.
Your users enter their passwords when they log in giving you an opertunity to replace their password hash.
So provided you have some policy on expiring inactive accounts you can switch to a new hash scheme (or the same scheme with different settings) over whatever your inactivity timeout period is without users noticing a thing.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
If only they'd built it with 6001 hulls!
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
And I talk about the old style 8 chars max unix hashes.
See some stats here:
http://openwall.info/wiki/john/benchmarks#Collected-john-test-benchmarks-for-one-CPU-core
and cracking the newest sha512 takes how long?
Atari rules... ermm... ruled.
Depends, is it using a whole disk encryption sheme ? And was the laptop turned off ?
New things are always on the horizon
I agree that, for most purposes, a few extra normal characters are rather more useful than a few weird ones, and much less of a pain to type. Plus, if there are applications that hook in to wherever you have your fancy-unicode password that aren't expecting non-keyboard characters, fun ensues.
I really only mentioned it because it can be kind of a cute trick. A dash of Akkadian Cuneiform probably doesn't add too much more entropy than would the same number of keystrokes of normal alphanumeric; but it is more amusing, and tends to place your password entirely out of the scope of any commonly available precomputed tables.
And That's we have a 256-bit encrypted luks /homes
I use 12-character passwords. http://howsecureismypassword.net/ [howsecurei...ssword.net] estimates that my root password would take 25 million years to hack.
Well, I also use a 12 character password, with at least one upper-case, at least one lower-case, at least one numeric, and at least one non-alphameric character. That web site estimates a mere 4 million years for a desktop PC to crack it. However, it does not indicate whether that's using the CPU or a GPU. Several orders of magnitude might vanish from that estimate if it is based on use of the CPU and a cracker uses a decent GPU. The remaining safety factor may become uncomfortably slim before long, given the performance improvements expected in GPUs and the parallelism inherent in password cracking.
The other posters are correct: passwords should be a necessary step in authentication, but by themselves should not be sufficient for authentication. After all, we can't expect to keep using longer and longer passwords (or pass-phrases). A few years ago, I was content with 8 character passwords for root (and sudo) accounts, and often containing only two character classes. Now it's 12 characters, containing four classes of character. Clearly, this trend is not good, as my memory for passwords is not improving at the same rate.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I have to add that the title *is* misleading. The 7 character password which was cracked in 17 minutes is alpha-numeric only. That hardly constitutes a strong password.
Including special chars, the 8 character password estimated 25 days to beat, while the nine char password of the same set, estimates a 7 year solve period.
I think the concept is very interesting and how this can be done! I still love it!
The simplest solution that I can think of is to use an authenticator system.
That way the passwords can be as simple as the users want, they do not have to be changed every 90 days (the duration of a password in our facility) and with the code changing every 60 seconds, it means that even if they somehow managed to snag your passwords, they can't do anything with them.
And I know that such a system is not fool-proof. But until someone develops a way to break that system it may be the simplest and the best solution for now.
-- Wiccan Army, 13th Airborne Division "We will not fly silently into the night"
That's assuming you know it's a phrase of exactly four normal English words long (no more, no less), what punctuation, capitilization, odd spelling or any other things could be in the mix. Even if you ignored all of that, even with 16,000 GPUs at your disposal, it'd still take you up to 6 months for *one* guy's password, The chances that you will be singled out as the target to the exclusion of all others seem slim. If you do have the attention of 16,000 GPUs dedicated to just you you must be a very special person of interest whose password is probably the least of your concerns.
XML is like violence. If it doesn't solve the problem, use more.
While that method is effective on a few individuals, it doesn't scale well to 1000's of accounts.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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.
It is well known that if someone gets your hashed password, it is as good as cracked.
It still depends on how much time / money the attacker is willing to spend. If you use slightly longer passwords / passphrases, then you won't be the low-hanging fruit. A dedicated, targeted attacker is still a big problem, but the opportunistic attackers will check the hashes, fail to crack them and move on to the next target.
I did an analysis on this a few years back, when CUDA and GPUs first started getting popular. Back then, my estimated speed was 5 billion hashes per second for a single GPU. A bit of an overestimation, but in line with the ~3 billion/sec of current GPUs. Passwords were assumed to be semi-random with 65% lower case letters, 20% upper, 10% numbers, 5% symbols. A big assumption, but it provides a starting point.
Very few attackers are going to spend more then a day on a single account. Even with a large botnet of 10,000 GPUs at their disposal. The ones that will go that distance are targeted attackers and they will be trying other methods as well to compromise your security.
Brute force times:
chrs
8 = 9 hrs
9 = 22 days
10 = 1325 days (44 months)
11 = 79,000 days
12 = 4.7 million days
13 = 282 million days
14 = 16.8 billion days
15 = 1 trillion days
The lesson from that was that 8 characters or fewer (of the stated complexity) passwords are screwed. You really have to go out to 11-12 characters and enforce some measure of password complexity to be safe.
Wolde you bothe eate your cake, and have your cake?
And what happens when it takes 10 seconds for one of your users to log in (not to mention what happens when you got multiple logins at the same time), and the attacker still can do a billion tries per second thanks to his GPU farm?
It's The Golden Rule: "He who has the gold makes the rules."
Does the strength of the encryption significantly affect the user's experience with passwords and encrypted files? I mean, if 256-bit encryption is better than 128-bit encryption, why isn't everybody using 32678-bit encryption or maybe megabit encryption?
It is impossible to have both. GPUs are only about 2000 times faster than CPUs at calculating hashes. A reasonable password policy ensures that passwords won't be cracked before users have time to react (usually months or years). Your example would require that a GPU be tens of billions of times faster than a CPU at hashing.
I guess what I'm saying is, from the perspective of one person who wants to protect their individual account, yeah, you might not worry too much. But if you're the guy in charge of protecting the server itself -- and by extension, the security of every account on that server -- then worrying seems justified.
Excessive worrying is only justified if:
- You allow passwords shorter then 8 characters.
- You do not enforce password complexity.
- You do not uniquely salt your passwords on a per-account basis.
Change at least two of those things and you're protected against opportunistic attackers (which is probably 99% of the threat). Force passwords to be at least 10-11 characters (I suggest 12-15). Force passwords to have at least some numbers / symbols / mixed-case feature. Make sure you use a different salt for each account, of at least 12 bits, for storing the password.
Maybe switch to a hash that takes 100x longer to calculate then MD5. (The other steps will buy you the equivalent or better time over using a difficult hash method.)
If the information is that valuable, consider adding a 2-part authentication system (password + token, or password + biometrics).
Once you drive the time to brute-force a password hash into the hundreds of years (even assuming that everything gets 1000x faster before we hit the physical limits of the universe), then you're pretty much done. No attacker is going to spend a year cracking a single password. Now you need to worry about the other dozens of ways to get at the information - like social engineering, exploits, vulnerabilities, sniffing, spyware, physical intrusion or intimidation.
Wolde you bothe eate your cake, and have your cake?
You're assuming that the cost ratio CPU / GPU will continue to be the same. That's not certain at all.
I can easily see both the per-card cost going down, and see per-gpu calculating power get increasingly ahead of CPU in these things.
It's The Golden Rule: "He who has the gold makes the rules."
It's not quite that simple... If you make a hash/crypto scheme that will be less vulnerable to this, you make it much more difficult to use it as a means for passwords in the first place as it's much more difficult to compute for authentication.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The rule of thumb that I've used is:
About 10,000 common words (13.325 bits).
About 300,000 words in a large dictionary (18.2 bits).
(Most attackers will probably attempt to build the pass-phrases out of common words first. It's a much smaller search space.)
Wolde you bothe eate your cake, and have your cake?
With the advent of password cracking power that GPUs bring, it does indeed look like keyspaces the size of 8.65x10^20 and similar that those who think about such things traditionally believed were reasonably secure is starting to become attackable by entities smaller than governments. This'll continue, and it should.
And, as always, risk assessment comes down to knowledge of your attacker. Are they opportunistic? Or are they specifically targeting you (insane attacker, country-sized government, or you are a high value target such as Sony)?
It makes a huge difference. The opportunistic attacker is defended against by merely not being the low-hanging fruit. The latter is generally a no-win situation because they will attack from multiple angles and their resources vastly (1,000,000 or larger multiplier) outstrip your resources. It's still worth being smart about your password hashes in the latter situation, but you probably have other larger security holes through which they will gain access.
Wolde you bothe eate your cake, and have your cake?
Or aren't able to turn on encryption because Macs can't do encrypted LDAP with SMB connections...
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
So, when do you forsee GPUs getting to the "tens of billions of times faster" that I mentioned above and is necessary for your comparison to be valid?
Keep in mind "Green peppers allow access." follows standard sentence structure. I'd wager that your passphrase would be much more difficult to crack if the capital letter was in some random place and the period was moved somewhere else, like "greeN pepp.ers allow access"
That's a good point I had not considered. It would take a rewrite or patch of most plugin authentication systems, but that would probably do the job.
Quadrupling the time it takes to crack a password is significant if yours is one of thousands and the attacker doesn't have the resources or will to crack them all. If your password is four times harder to crack than everyone else's, it may be skipped. Just like any security measure, passwords are never absolute protection.
Any security measure from a closed door to a combination lock to an army can be overcome with enough resources and will. Sufficient security is something that requires more resources or will to overcome than the attacker possesses or just delays the attacker long enough that the attack can be rendered useless. In the case of password hashes being obtained by an attacker, the longer it takes for the password to be cracked, the greater the chance the victim can be made aware of the attack and change the password or take other measures that render the attack useless.
Isn't it better to simply get the public RSA key of the user and be done with it? You get a 2048 bits key that won't need replacing often (good till the heat death of the Universe), won't burn your money into useless server cycles (fast algorithm), and is still more secure (older, way more tested than your idea). We just need to adapt the browsers, untill then you just don't limit the size of passowrds on your site, so people can protect themselves with longer ones.
Rethinking email
I can confirm this as true because every single person responding to this thread is actually me. Getting everyone's password was a breeze. Logging into everyone of them and posting something different....... that was a pain.
Does God treat us as servants or friends? Check my homepage.
Your point is not really true at all because you fail to take into account the scale of turning a few microseconds per calculation into a several seconds calculation. I just made it cost a million times more to crack passwords. There are no 10 billion machine botnets.
You think a 2-factor system is more user friendly than limiting authentications to roughly 35 logins per hour per quad core system? Having to wait in a queue seems less painful to me, and less likely to line the pockets of RSA Security.
“Common sense is not so common.” — Voltaire
Which is why Secure Remote Password was invented. It's pretty secure for a password-based authentication protocol--much more so that HTTP Basic or Digest.
If you get access to the hashed password, there's little else that'll slow down hacking attempts. Either make the hash take longer, or make the password more complex.
Funny, l0phtcrack did a great job of pulling in NTLM hashes over the wire.
- Michael T. Babcock (Yes, I blog)
The post I replied to suggests stopping at the first collision. Perhaps the question was poorly worded. I would like to know how many collisions occur for a given hash. Could this be calculated without a brute-force attempt or is that the only way?