New 25-GPU Monster Devours Strong Passwords In Minutes 330
chicksdaddy writes "A presentation at the Passwords^12 Conference in Oslo, Norway (slides), has moved the goalposts on password cracking yet again. Speaking on Monday, researcher Jeremi Gosney (a.k.a epixoip) demonstrated a rig that leveraged the Open Computing Language (OpenCL) framework and a technology known as Virtual Open Cluster (VCL) to run the HashCat password cracking program across a cluster of five, 4U servers equipped with 25 AMD Radeon GPUs communicating at 10 Gbps and 20 Gbps over Infiniband switched fabric. Gosney's system elevates password cracking to the next level, and effectively renders even the strongest passwords protected with weaker encryption algorithms, like Microsoft's LM and NTLM, obsolete. In a test, the researcher's system was able to generate 348 billion NTLM password hash checks per second. That renders even the most secure password vulnerable to compute-intensive brute force and wordlist (or dictionary) attacks. A 14 character Windows XP password hashed using LM for example, would fall in just six minutes, said Per Thorsheim, organizer of the Passwords^12 Conference. For some context: In June, Poul-Henning Kamp, creator of the md5crypt() function used by FreeBSD and other, Linux-based operating systems, was forced to acknowledge that the hashing function is no longer suitable for production use — a victim of GPU-powered systems that could perform 'close to 1 million checks per second on COTS (commercial off the shelf) GPU hardware,' he wrote. Gosney's cluster cranks out more than 77 million brute force attempts per second against MD5crypt."
my password (Score:5, Funny)
So it doesn't matter anymore I'm using 000000 as password ....
Re:my password (Score:4, Funny)
Re:my password (Score:5, Insightful)
1.... 2.... 3.... 4.... 5....
29 characters, including spaces...not bad. As long as the attacker doesn't know anything about your password and has to test all ASCII printable characters, that's over 180 bits of entropy in your password. So I think you're safe - the article says it would take 5 hours to hack an 8 character NTLM password. (which is not the same as LM (WinXP))
I think NTLM only keeps a 128bit hash, so if it were possible to brute force the entire key space, the attacker would likely find a hash collision that works as your password before finding your actual password.
Re:my password (Score:5, Insightful)
My door lock is even more secure with a 4 digit pin. 3 failed attempts lock it out for several minutes. More failed attempts lock it for an hour. It doen't bother to tell you it is ignoring you during that period. A penalty instead of millions of free retries should stop that without physical access.
Re: (Score:3)
This sounds vulnerable to a DoS attack, though. If I walk up to your house and enter a random pin a couple of times you are effectively locked out from your own home for up to an hour.
I'm sure that this lock also contains a physical key, to prevent this exact thing, as well as if the battery dies. All you've done is made it a little inconvenient to get into his house.
Re: (Score:3)
How will they get the password hash without first breaking into the system? Seriously, how useful are these brute force crackers in attempting to crack, for example, my gmail password?
Re: (Score:3, Funny)
That's awesome! I didn't know Slashdot had that feature! When you type hunter2, all I see are stars where hunter2 would be! And when I type my password ******* everyone else gets these stars!
Re: (Score:3)
Oh, so if I type my password, berzerk76, you'll only see stars? Awesome.
...
Dammit! Now I have to go and change all my passwords. You b**tard.
Re:my password (Score:5, Informative)
To all you gloom and doom people out there, here's my suggestion. If your password is monkeys1459, change it to monkeys1459monkeys1459. That's 22 letters and equally memorable.
You are assuming that the password test function doesn't text the pattern XX i.e. the same string repeated.
Password crackers actually test a number of permutations, like adding every digit 0-9 to the end of the string, reversing the order of characters, setting the first letter to uppercase, setting all the letters to uppercase, AND, repeating the password.
So your little "trick" is already outsmarted by today's password crackers.
Re:my password (Score:5, Insightful)
And many password strength checkers don't catch that either and let you think you are picking a good password.
Single factor authentication has had it's run. Now it's deader than a doornail. Time to move on and stop living in the past.
Re:my password (Score:4, Insightful)
I think it is time that we moved to two factor authentication as a whole.
What would be nice would be if there was one secure time/event based standard across the board for the authentication keyfob. OATH comes close, but there is always people/enterprises using SecurID. Perhaps something like the Google Authenticator, except with a stronger [1] hashing algorithm.
Ideally, it would be good to have multiple hardware devices, just like one keeps more than one key to a vehicle, and this can be a smartphone app, a dumbphone/featurephone app, a dedicated token like a Blizzard Authenticator, or a device that gets power when plugged into a USB slot.
One can add biometric authentication before the device offers the 6-8 digit code as well for three factor authentication (what you know, what you own, what you are.)
[1]: Perhaps multiple algorithms with the output XOR-ed together so if one algorithm is weak, it won't affect the unpredictability of the outputted numbers.
[2]: Reason one has it run from a computer is so it does not need to worry about having a battery. Even the best lithium ones eventually will fail in a couple years.
Re: (Score:3)
Use different passwords for different things (Score:5, Insightful)
As long as the passwords are strong enough to prevent brute forcing over the _NETWORK_ they are strong enough. If you don't pick an overly stupid password then either you or the site is going to be pwned before the hackers brute-force/guess your password over the network.
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
Re:Use different passwords for different things (Score:5, Insightful)
Pretty much this. Brute forcing passwords over the Internet is silly and non-productive.
>it's likely they can do other stuff anyway
What, you mean like the Youporn chat registration list that had the usernames and passwords *and* verification email addresses in plaintext? Or like when Yahoo was compromised? Or like dozens of other companies were compromised? Or like when EMC was spear-phished out of RSA tokens?
My concern isn't someone with a hundred Tesla cards cracking passwords. My concern is dumb admins and people falling for social-engineering.
--
BMO
Re: (Score:2)
Yahoo properly hashes
Re:Use different passwords for different things (Score:4, Insightful)
> My concern is dumb admins and people falling for social-engineering.
It's as soon as we stop claiming that it's just stupid people who fall for social-engineering that we'll finally get better at avoiding it.
Re:Use different passwords for different things (Score:4, Interesting)
>They that is account provider can easily use delays and lockout an account after too many tries.
Not lock out an account.
Temporary ban an IP address. Fail2ban does this. If you're just looking to protect SSH, use Denyhosts.
You don't want to lock out legitimate users. All the big providers like Yahoo and Facebook will let you keep trying at a password 3 times, and then they'll throw a captcha at you for all tries after that with as many tries as you want, because you have to keep solving the captcha for each attempt. Current captcha technology is pretty much bot proof - almost human proof sometimes, it seems (as a user, I hate captcha and knowing someone who is sight impaired, I consider it offensive - we should find something else, something better).
Locking out accounts over bad login attempts generates too many support calls and upset users, because you could DOS attack an account simply by spamming the login with bad passwords. It's been tried. It sucks as a solution. The solution is to make brute-forcing time consuming and requiring human intervention.
--
BMO
Re: (Score:3, Informative)
Or, as a developer, just limit the number of tries per second to 1. Easy to implement, no need to lock out anyone or ban anyone or even engage tech support at any point. And the cracker can have a million GPUs - doesn't matter. They'll only be allowed to operate with the speed of a 1970s calculator.
Re: (Score:3)
Don't block accounts, ever...
This causes inconvenience for the legitimate user of the account, and gives the attacker a trivial avenue for causing intentional disruption - if i know your username, i can lock your account out continuously causing you a major headache.
Also for any target of a significant size you don't try thousands of passwords against 1 username... You try 1 password (theregister published a list of the most common passwords a couple of days ago - start there) against thousands of usernames
Re: (Score:2, Insightful)
In other words, why would a hacker who has already had an access to the server attempting to crack passwords over the Internet? Why not download (make transaction) the data and crack them locally?
The point is that, as long as you don't use the same password for multiple sites, cracking your password wouldn't allow the attacker to do anything they couldn't already do, since they've already broken into the system the password was supposed to protect.
Re: (Score:3)
Re:Use different passwords for different things (Score:4, Insightful)
Re:Use different passwords for different things (Score:5, Informative)
But the issue is not brute forcing over the network. The issue is hackers stealing a database of passwords, then bruteforcing the lot of them locally. Some sites don't even bother to hash the password at all and some don't salt them or use a weak hash. So if the database is lifted, the hackers could potentially recover some or all of the passwords with little or no effort. So if you use the same email and password for an insecure site as a strong site, you are trouble.
Therefore it would be wise to arrange sites into tiers of importance. Tax / health / social security on the top. Then banks. Then cloud / email services. Then stores. Then sites with personally identifying info. Then forums and other throwaway crap. For each tier take appropriate measures to ensure uniqueness of the password and login id and use password safe to manage this mess. On the bottom tier, you could probably use the same throwaway password for every site, or a variant of it (e.g. tack on the first 4 letters of the domain host) since a compromise is a nuisance rather than as a threat.
And use something like Password Safe so you don't have to remember all this crap.
Did you even read the GP's post? (Score:3)
If anyone with motivations beyond that of a script kiddie is doing this, then you are already totally screwed - they can already steal all your transaction information or make their own transactions or transfer funds or do whatever they want to do as ANY UID in that system - WHY would they ruin that and post them on the web?
And if it *IS* a script kiddie,
Re: (Score:3)
I've often thought about trying something like Password Safe, but I commonly use 4 different computers that I might need my passwords on. And 3 of those are at home where I might be accessing a bank. So unless there's some way around that problem I'm not thinking of, I'll stick to my main 6 or 8 long random ones.
Ha, what I really need is some sort of cloud password service. Wait...
Re:Use different passwords for different things (Score:4, Interesting)
I'd echo the other suggestion to use lastpass. I was struggling with the same issues. In theory the passwords are encrypted/decrypted locally and they do not have access to them. Of course, I'm sure they could be bruteforced as with any of the other sites. That said, I am a bit more inclined to trust one site whose sole purpose is storing passwords than every web forum on the internet. These days most of my passwords are randomly generated thanks to lastpass.
The real pain has been with smartphone apps, which don't integrate well with lastpass. I can access my passwords on the phone, but I have to do copy/paste to get the password into the app, and some apps are brain-dead and reset when context-switching which means I need to at least manually enter the username (which is a pita if it is a long email address).
People also point out keepass, but it doesn't support every OS I use. Lastpass always has the browser as a fallback if nothing else.
Re:Use different passwords for different things (Score:4, Insightful)
Thanks for the idea, and I hadn't heard of Lastpass, so I looked them up and found this [wikipedia.org]. Stuff like that, while probably never likely to affect me personally, still scares the hell out of me.
Yes, that's just one site. But if one site I use has their PW file stolen and broken I lose out on one site (and potentially any others I've used that specific PW for). If I trusted something like lastpass with my entire life and then they were successfully hacked...
Re:Use different passwords for different things (Score:5, Interesting)
That episode is the main reason why I've stuck with them - I was a customer at that time.
When that breach occurred nobody knew about it but them, but they immediately broke the news and generally treated the situation in the most conservative manner possible. Their treat assessments as communicated out seemed accurate to me.
So, sure, you're more secure if you never put your passwords out in the cloud to begin with - nobody can question that (assuming you still use strong unique passwords for each site and just carry them around with you on a PDA or USB drive or something). However, if you are going to use a cloud service then would you rather use one that has an episode like this and does full disclosure, or one that puts the marketers in charge and covers the whole thing up? The only reason you can cite that example is because Lastpass did the right thing.
If the alternative is to just pick a few memorable passwords and use them on many websites each, I'm not convinced you're better off.
Re:Use different passwords for different things (Score:5, Informative)
I keep my Keypass database in Dropbox. That way it's synched to all my machines, or I can download it to my phone, or access it via a web browser.
Re: (Score:2)
Re: (Score:3)
Therefore it would be wise to arrange sites into tiers of importance.
That seems overly complicated - trying to accurately assign risk levels to different websites is beyond most people, and can potentially change out from under them if a website decides to increase its scope.
Here's what I do -- create a "base" password that is uber-secure, random line-noise sort of thing. Then I use a really simple algorithm where I take something from each website's name and prepend it to the base password (prepending is important since some websites silently truncate passwords).
So, for e
Re: (Score:3)
I use a very similar setup, however one issue with the example you've given is that by using the first two letters of the domain means that even a bot could be written to compare the first N charaters of each password to the domain, and can make an assumption on what another domain's password could be. I know, it's a stretch.
A slightly better method is [for example] to prepend the first 2 vowels and append the last 2 consonants to the password. Sure, you have to remember slightly more complicated rules, and
Re:Use different passwords for different things (Score:5, Insightful)
i think email should be on the top list of priority - because "reset your password" on every other system tends to use your email address. lose control of your email and you've lost control of everything else.
Re:Use different passwords for different things (Score:4, Insightful)
This person deserves +5 Insightful.
An online email account often comprises the keys to the online kingdom. From looking at the email history you can often learn what usernames and accounts a person has on other services, and then reset all the login credentials for those other services. I'm pretty sure I remember reading about that exact sequence happening to someone high profile quite recently.
Re: (Score:3)
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
This is not always true tbh. Stealing hashes can require as little as an unsanitized SQL query in a web application that allows an attacker to dump the hash table(s) using nothing more than a browser. It may or may not allow for user impersonation in order to do the stuff you listed, but the point is stealing hashes does not have to require complete hacking. In such a scenario strong passwords are still quite useful.
Re: (Score:2)
A strong 12 char password has 612,709,757,329,767,363,772,416 possibilities, which even at quadrillion(10^15) guesses per second, it would take over 7,000 years to exhaust the entire space.
Re: (Score:2)
crap system is proven to be crap (Score:4, Insightful)
So now that passwords as a system is officially broken, can we please move on to something better? Something that wasn't invented to allow soldiers standing watch in the middle of the night to tell their mates from their enemies, but is actually designed for computers?
And no, of course I don't have any better ideas... this is /. and I'm here to pointlessly criticise!
Re:crap system is proven to be crap (Score:4, Insightful)
This system cracks password hashes. But there's one thing missing: You need to get your hands on the password hashes first!
Therefore you require access to a system. If you already have access to that system it's fairly trivial to install password capturing code. That way you don't even need to crack any hashes.
The problem remains that a hacker who gains access to a badly secured system can do almost anything he likes. Secure hashes or not.
Re:crap system is proven to be crap (Score:4, Interesting)
If you already have access to that system it's fairly trivial to install password capturing code.
The whole point is to engage in defence in depth - FreeBSD offers kern.securelevel to prevent you from being able to write to the file system, or change firewall rules. We have anti rootkit checking programs (do most people make regular use of rkhunter or anything similar?) Further, you need to encrypt and safely store backups. No password logging program is going to lift them from the hashes you got from the borrowed backup drives. Probably 60% of engagements I have been involved in managed to lift a backup drive from the environment, permitting only the tiniest changes to be made to live servers, thus minimising our risk of breaking things, and a (potential) black-hat's chance of being caught.
Making the hashes harder to crack makes it harder to crack into the server, live or from backups. You'd be surprised how many people forget backups.
Re: (Score:3, Insightful)
Already have. Public/private key pairs, one of the modes of SSH. (And by far the preferred mode.)
Yes, we are rapidly approaching the point where the only way to secure a system is something you have, not something you know. Or at least, not solely something you know. That's all right. We're used to that. How do you start your car? Or open the door to your house? Something you have. And for any expensive car made in the past decade, that something you have isn't just the physical shape of the key.
Re: (Score:2)
http://en.wikipedia.org/wiki/Contactless_smart_card [wikipedia.org]
http://en.wikipedia.org/wiki/Octopus_card [wikipedia.org]
Re: (Score:3)
Because house keys and car keys are known to be secure devices.... (And before you get started on the new electronic keys, go ask BMW M3 owners how that's working out for them)
The nice thing about a key chain is it makes it possible to lose all your keys in one go.
Re: (Score:2)
Agreed, but what we're likely to first see is every Bank and significant e-commerce site making you pay $5 for a dedicated keyfob, so that you now have to carry around a huge collection of them. It will turn out that half of them have other security problems, but that's OK since you're the one who had to pay for them.
What we really need is something like a strong two-factor openid system, or something like that. OpenID can already support this, but the problem is that few sites actually support OpenID. I
Re: (Score:2)
Right, then you have to login to some service from another computer....
Re: (Score:2)
Right, then you have to login to some service from another computer....
If it's something that is really high security, Don't Do That Then (and you certainly shouldn't be doing it using a password).
For normal "domestic" security, carry a USB dongle containing your private key and enough processing power to encrypt challenges. For 'belt and braces' add a PIN, password or fingerprint reader needed to unlock the device. For belt, braces and really thick underpants have a second PIN or password checked by the service you are connecting to.
(Of course, this needs someone to estab
Re: (Score:2)
It's only weak passwords when you have access to the hash database what's broken. You can always throw in more characters to make brute-forcing take exponentially longer. And since some hashes have been proven to be NP-hard, there's nothing you can do better than brute-force them. No useful hash can be harder than NP, but I'd say that's good enough for me.
Also, in a majority of cases, if you can obtain password hashes, you may just take whatever was protected by that hash. Not always:for an encrypted fi
Re: (Score:2)
Re: (Score:2)
No it means that if someone can steal the password hashes then your passwords are known ....
Why is the database of passwords on a machine that is capable of being stolen in the first place, this is like the soldier having a list of challenges and responses written down where anyone he challenges could potentially see the entire list ...
The solution is for the user facing machine not to contain the hashes just an API to check individual passwords as needed
This is hype: NTLM is broken by design (Score:5, Insightful)
Re: (Score:2)
That's why the article say it's million times easier to crack than even md5crypt
Ob "correct horse battery staple" (Score:5, Informative)
A customer asked us recently if we could recover some of their passwords stored (hashed) on our system.
"Sure we can, if you used really poor passwords."
Re:Ob "correct horse battery staple" (Score:5, Insightful)
You mean your system allows users to enter weak passwords?
XP Passwords (Score:4, Insightful)
I was under the impression that a 14 character NTLM password was basically two 7 character passwords, and the fact you can crack them easily is not news. Rainbow tables will crack them in a matter of seconds on a standard PC setup.
Re:XP Passwords (Score:4, Insightful)
Re: (Score:2, Funny)
Soon, they will be able to build a time machine entirely out of GPUs to go back in the 90s and crack those passwords!
Re: (Score:3)
You are describing LanMan (LM) hashing, not NTLM. And it is even worse than being limited to two runs of 7 characters, they are upcased before hashing so mixing case has no impact. NTLM still sucks (and there are rainbow tables due to the lack of salting), but it is a major improvement over LM.
Just as a note: using a rainbow table will crack the password very quickly, but that is because you (or someone else) expended a lot of computing time to generate those tables. And those tables take up space. Not much
Do the math. (Score:2)
Let N be the number of bits of real entropy in an item of human memory. N is somewhere between 50 and 70. (Proof: you can remember RWOLZEKBYT or "correct horse battery staple" [xkcd.com] if you have to, but you've got no prayer of remembering RWOLZEKBYTDUQLZPEJNB or Rw3L$E5Kÿ(t. )
Let 2^R be the instruction rate of the largest computer affordable by a large nation or corporation. R is about 56 at the moment.
2^(N - R) is the number of seconds before we're all completely fucked.
Re: (Score:3)
(Proof: you can remember RWOLZEKBYT or "correct horse battery staple" if you have to, but you've got no prayer of remembering RWOLZEKBYTDUQLZPEJNB or Rw3L$E5KÃ(t. )
But I can easily remember "correct horse battery staple waterslide fishnet the queen bleach" - how much entropy is that?
Can it bust my neighbours WPA wifi setup? (Score:5, Funny)
I'm really low on porn at the moment and hit my monthly internet quota!
WPA keys per second? (Score:2)
Not seeing anything about WPA.
You can pull those truly out of thin air and since they are rehashed 4000 times brute forcing those is slow even on most modern hardware. Generally in the range of a 1000 to 5000 keys per second.
More than a thousand years for a 8 character password. And you can't even use a shorter password on WPA.
GPUs do change the picture a bit.
So...what would the solution be? (Score:5, Interesting)
If passwords are getting cracked so quickly these days, what then is the answer? Authenticators are all well and good, but I don't have room on my keychain for one for Blizzard (I know about and have the one for my iPhone), one for Amazon, one for PayPal and eBay, one for Gmail, etc and so forth.
What would be a viable solution then?
Re: (Score:3)
LastPass. Separate, strong passwords for every site; one YubiKey for the master login if you want it. KeePass is good too; store part of your key on a dongle for extra security.
Server-side code (Score:2)
So it seems all server side code should be storing:
algo_name, hash(salt + password) ...that way, if your algorithm of choice proves to be a bit feeble, you can gradually upgrade to a better one by getting your users to change their passwords. If anyone's account has a really old algo still on it, then the account gets disabled. Whilst this doesn't "solve" the problem, it means you don't have to throw everything away because someone found a quick way to compute hashes using your chosen algorithm.
Either way,
Fingerprint scanner / twist (Score:2)
Don't know about you, but I'm already set.
But can it... (Score:2)
Crack the code to open President Skroob's luggage?
NTLM (Score:3)
Which is nothing impressive. NTLM has a 14 char password max and pads sub-14char passwords with null. It then breaks the password into two 7 byte pieces, hashes both pieces, then concatenates the two hashes together. Using NTLM, a 14 char password at worst 2*96^7 instead of 96^14, which is a factor of 37,572,373,905,408 difference. If NTLM was properly designed, that same 14 char password would have taken 37,572,373,905,408*6min to break or 428,908,378 years.
14 char passwords are still safe assuming there isn't a huge flaw in the password storage.
DRM encryption? (Score:2)
How the hell do you pronounce (Score:2)
Passwords^12?
Passwords carrot twelve? WTF kind of a name is that?
Re:Lockout? (Score:5, Informative)
that's not the context this sort of thing works in.
passwords are stored as hashes. for example of you log into a terminal you don't want the terminal sending your pass over the network.
So it pulls down a list of hashes and compares it to the hash of your password. or it hashes your password and sends it over the network.
The idea is that someone picks up these hashes and then brute forces them at home.
not that they keep trying to log into your account one attempt at a time.
Re: (Score:3)
The server sends a random string of digits to the client and says "encrypt this using your hash as the key". The client does so and responds with the encrypted data. The server, since it knows what the user's hash should look like, can then duplicate the encryption function and compare the results. The server will never see the plaintext of the password, and the hash will never leave the application space on either end, and replay attacks are impossible since the random string will be different every tim
Re: (Score:2, Informative)
That doesn't work for systems with password files. Once a system's password file (which includes the hashed passwords) is compromised, then the password programs just compare their generated hashes against the file.
We had an old ATM testing machine that ran a dinosaur version of x86 SunOS and didn't have the root password. We were able to use a FreeBSD CD to mount and recover the shadow password file and used John the ripper to crack the passwords. Ran it for a month on a dual processor 8GB rackmount.
Re: (Score:3, Insightful)
mount the SunOS disk, write a new password hash into
Does not take anywhere near a month!
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re:"Strong" (Score:5, Interesting)
For comparison, the password to an account I use fairly often is 128 characters.
That must be annoying to type in every time.
More seriously, if that's a password but the system in question is only storing a relatively short hash of it, all the attacker has to do is find something that hashes to the same thing. That's pretty simple to do if you've got the grunt compute power, as there's usually no other checks on the sense of a password at the point of use (which isn't the same as the point of definition). In effect, you're not hindering attackers at all but you are making things worse for yourself. Congratulations on your addition to Security Theater! With thinking like that, you're almost qualified to work for the TSA...
(Myself? I disable logins with passwords wherever I can. Turn up with a cryptographic key — the verification of which is not a hashing operation at all — or don't turn up at all.)
Re: (Score:2)
"That must be annoying to type in every time."
Not if you have a modern password manager.
http://www.roboform.com/ [roboform.com]
Re: (Score:2)
Re: (Score:2)
Crack times based on a password composed of 70 possible base characters:
algorithm-attempts
based on: 6 character,10 character,16 character passwords
MD5-180 billion attempts per second
0.65 seconds,182 days,117 Eons
SHA1-63 billion attempts per second
1.67 seconds,519 days,335 Eons
LM-20 billion attempts per second
5.88 seconds,1635 days,1053 Eons
sha512-364 thousand attempts per second
89 hr 47 min,246 077 years,57901611 Eons
bcrypt05-71 thousand attempts per second
19 days 4 hr,1.26 million years,...A really long ti
Re: (Score:2)
What type of hardware are the 'attempts per second' values derived from?
Re: (Score:2)
You're propagating security through bogosity.
Let's take one of these clusters, and get it to crack an arbitrary 14-character password using upper and lower case letters, digits, and some of the more reliably-typeable symbols:
((26+26+10+5)^14)/77e6/86400/365 = 15,126,898,948 years = the age of the universe.
You can multiply that by ten if you throw a dozen more symbols into the alphabet (taking you up to 88 bits of security). If you consider th
Re:"Strong" (Score:5, Interesting)
And flagging this:
http://www.schneier.com/crypto-gram-9902.html
Snake Oil Warning Signs
Warning Sign #5: Ridiculous key lengths.
Re: (Score:2)
Re: (Score:2)
Then, something DID happen to me; I got a warning from the Guild Wars
Re: (Score:2)
I'm not the GP but there are a few measures that can be considered such as
1: deliberately slow hash functions. You can make the crackers job a few orders of magnitude harder this way.
2: dedicated password checking servers (ideally a seperate machine but privilage seperation on the same box is better than nothing) so that cracking your webapp doesn't hand the attackers the password hashes on a silver platter.
3: physical hardware the user is given that provides one-time use security codes
Of course none of the
Re:Time delay? (Score:5, Interesting)
This isn't about live attacks on a system. This is about "offline" attacks and even things like hash collisions (where someone can make a certificate or a download that has the same hash as the "official" one but is fake or contains malware, etc.).
If you can take a login system and run millions of queries against it, it's a stupid system. But if you can steal a hashed file of password, or old hashed tokens from the network, then you can theoretically break them now in the time it takes to reboot the computer (if you could log into this other system remotely).
Things like the Sony break-in would reveal everyone's password, not just the other stolen details. And on a local network, you could sniff tokens sent for NTLM services etc. and start impersonating other users before it could even be detected. Of course you have to have a certain level of compromise / access already to get to that stage, but it doesn't make it any less dangerous to be able to forge hashes or find out their plain-text.
Please note, also, that things like these hashes have been used historically to verify software is genuine, as part of encryption algorithms, random number generators and all sorts of other things. At the time, they were reasonably unbreakable, but now they aren't. And that breaks lots of things if they are still relying on them.
Impact to security-conscious users: Zip.
Impact to security-unconscious users: Huge.
Re: (Score:2)
Re:...and what? (Score:4, Informative)
That isn't exactly how rainbow tables work. In fact colliding chains is undesireable for rainbow tables. While it is true that you might end up on another "chain" the odds of that are exceedingly low with even 128bits of hash space and any decent salt.
The reason for itterating a password hash it to slow it down, to try and thwart brute force, however it doesn't work that well against GPUs since they have so many cores to work with and VERY efficient implementations of the algorithms. Some password hashing algorithms (I believe bcrypt is of this sort) can be tuned to take more memory and, this, keep GPUs from working much if any faster than a normal CPU. This, really, needs more research but the principals are simple: make memory access patterns impossible to predict so you can't stream in cache lines and make the space required "large" (lare isn't HUGE, I think a few megs is large enough. You won't find this in a normal cryptographic hash as they are *designed* to be fast, and that is a good thing for every use aside from this)
Rainbow tables work in chains, as you said, but what they do is they generate a hash from a "seed" for each chain THEN they "map" that hash back into the password space, and then hash that, map, hash, map, hash, da da da. Once you do this for a good long ways you store the final hash and the seed for this chain. You have MANY chains.
To find a password from the hash you pick up right in the middle of that. Lets go step by step:
You have a hash to reverse
1) check the hash against your "end of chain" hashes
2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space
3) repeat until you find an "end hash" and therefore the chain, or you find that this password isn't in your table by mapping-hashing more times than you used for the chains
4) assuming you found the end hash you then take the "seed" for that chain and start hashing and mapping it over and over until you find your original hash
5) the password that you hashed to get there will be the correct one
So, yeah. Lots going on and many subtle problems that can creep in, but the chances of a collision due to itterated hashing aren't large. Smaller than anything you'll ever need to worry about. Like I said, too, itterated hashing doesn't help much against GPUs
Re: (Score:2)
The kind of action described here is more an army of monkeys on typewriters trying to guess passwords off a stolen list of passwords; eventually, they'll get it. They won't know they've gotten it unless they already had (the hash of) your password to begin with, but that's doa
Re:first (Score:4, Funny)
Re: (Score:2)
Re: (Score:3)
Would be more interesting to see the results from an attack on a SHA-512 hash of a 15 character password. Stuff like that isn't that uncommon in many web applications out there.
Nowadays, MD5 offers mostly decorative value, whenever you want something unimportant to have a more uniform look (e.G. public reference IDs for blog entries).
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:5, Insightful)
There problem is there is still tons of old sites that have MD5 storing passwords. Then there is the second problem of password reuse. Username/Password reuse is the more dangerous of the two, because it can render an account on a system with strong passwords where then local attacks can be attempted.
Re: (Score:3)
Everyone using their email for the username and the same password everywhere means one hacked site, all hacked accounts :(
Lastpass ftw
Re: (Score:2, Informative)
Exactly, using rainbow tables located on an ssd a 14 digit LM password can be cracked in under 30 seconds. Now if you instead have a 15 digit password which invalidates the stupid LM hashing algorithm (or you just turn off LM hash generation, but that can break things) then breaking the resulting password is going to take a good long while, 72^15 is a big number.
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:5, Informative)
Who gives a rat's ass about such golden oldies? It's been possible for the longest time to fairly quickly crack windoze passwords (if you have the file) and MD5 has been known to be insecure for quite some time already...
Yes and no.
LanMan hashes have been brute forceable for a long time but neither proper NTLM nor NTLM2 have, so hacker have had to "trick" clients into sending the LanMAN hash, or recovering it from the SAM file.
Another trick that is often used to secure the password is to simply not support LanMan.
one little known fact discovered by Urity of SecurityFriday.com is that if a password is fifteen characters or longer, Windows does not even store the LanMan hash correctly. This actually protects you from brute-force attacks against the weak algorithm used in those hashes. If your password is 15 characters or longer, Windows stores the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is equivalent to a null password. And since your password is obviously not null, attempts to crack that hash will fail.
So, yes and no, security consious companies have been able to protect themselves from brute forceable passwords for over 10 years.
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:5, Informative)
No and no...
If a windows box is trying to connect to you (ie single sign on so it tries to auth to you), you don't need to trick it into sending the lanman pass, you can just reflect it back (google: metasploit smb_relay). But your talking about the network level NTLM, not the hash stored on disk. You can indeed try to brute force the NTLM challenges, if you wanted to.
You can brute force NTLM hashes (the disk stored kind) easily, the hashing itself is very weak compared to anything used on unix for many years.
On the other hand, you can exploit a design flaw in the aforementioned network authentication protocols which let you use the hash for authentication (google: pass the hash) - that is you don't need to bother cracking it at all, just use it.
As for where you get hashes....
Backups.
Local admin hashes on workstations etc (usually they are all the same on a large organisation)
From memory when users are logged in which includes service accounts (google: gsecdump) or you can even extract the plaintext (google: mimikatz)
Typically you only need to find a single insecure system and you will be able to compromise an entire domain within minutes, even when most machines are fully updated and/or hardened.
Re: (Score:3)
You can actually lock that down in the profile manager (yes, there is a "no-login" profile). You can take away the abilty for users to access programs and run executables, which means the OS is "practically" locked-down.
The only downside? The same "no-login" profile is required for accessing Safe Mode, so if you have an unrecoverable problem be prepared to reinstall :D
Re: (Score:3)