Cheap GPUs Rendering Strong Passwords Useless 615
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? (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Whenever a company "loses" a database with passwords, we scorch them for storing plaintext passwords. If hashing is supposed to help, then it has to create a significant barrier. As the processing power required for brute forcing password hashes makes longer and longer passwords insufficient, it should become clear that the age of passwords as the sole authentication is coming to an end.
Re: (Score:2, Informative)
Re: (Score:3, Insightful)
Like this article shows, they're basically equivalent given enough processing power. The end result is the same; the "hidden" information becomes known, with relatively little ease. Sure, salting may currently help make the brute-force "decryption" of a hashed password more difficult, but hardware is always getting faster and more powerful.
Re: (Score:3)
hashing != encryption
No the parent poster was correct in his/her terminology. Encryption is what you use if you want to get the original data back again. Hashing is what you use when you only need to prove that the supplied information matches the original information. The latter is the best way to store passwords for user authentication. To be useful, you don't need to know what the original password was, you only need to know that the password the user supplied hashes to the same value as the stored hash.
If the company is sto
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Realistically, we need to have passwords as *an* authentication method, as opposed to *the* auth method.
Until we can decide on another method of authentication, perhaps one thing to do is have the mechanism that does the password validation (as well as storing hashes) physically secured on a tamper resistant card, similar to how public keys are stored on HSMs.
The mechanism on the tamper resistant card would have ports to store data on external media (encrypted with LUKS where the whole drive is encrypted wi
Ha Ha, mine goes to 11 (Score:5, Interesting)
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).
Re:Ha Ha, mine goes to 11 (Score:4, Informative)
Re: (Score:2)
Password pharses are easier to intercept (and remember) if someone is looking over your shoulder. Even if they skip a character or two they could still guess the word.
Re:Ha Ha, mine goes to 11 (Score:5, Insightful)
But the number of potential attackers is significantly diminished. And he did mention deliberate character substitution, which helps against that (as well as helping against dictionary attacks).
Re: (Score:3)
Why not just stick 20 'F's in front of all of your passwords?
Easy to remember, hard to brute force.
Re: (Score:3)
Re: (Score:3)
Re:Ha Ha, mine goes to 11 (Score:5, Informative)
Exponential growth. Get the point?
Using the same scaling as the summary, you can crack 8 characters with about 64 GPU hours, which is about $50 on AWS.
By the time you get to 10 characters, you are talking $700k. 12 characters is into the billions. Of course, I doubt that AWS will scale their fleet to billions of servers just so you can rent it for one hour, so you're going to have to pay to build your own data centers and, for that matter, chip factories.
Re:Ha Ha, mine goes to 11 (Score:4, Informative)
And that's just to get ONE password. Unless you know what you are going after, you probably aren't going to put in that much effort. And you most likely won't know ahead of time going into it if the password is short enough to be worth even trying (although I suppose you could make some calculated risks here).
Re:Ha Ha, mine goes to 11 (Score:4, Interesting)
You're right of course, but I'd like to chime in with another observation: people don't grow the size of their passwords to counter Moore's law.
Statistically, the human population will choose an average (rather low) size of password, and that's going to stay constant over time. When faster machines appear, the average amount of time required to crack a significant fraction of human passwords goes down.
Re: (Score:2, Interesting)
Single point of failure.
Essentially, you will need to carry a copy of your password bank with you AND the application which opens it at all times to function.
This means that if it gets compromised (your memory stick gets stolen/your dropbox account gets compromised/ etc...) an attacker will only need to guess/bruteforce/dictionary attack/social engineer/look over your shoulder one password and gain access to everything in your wallet.
Its not a bad plan in principle, but only if you keep important passwords
Re: (Score:2)
This attack is only useful if the attacker can access the password file, it can be trivially stopped remotely by enforcing a delay of 1 second between login attempts. The lesson here is for website owners to keep their password files safe, because users WILL be vulnerable. Implement multiple layers of security around the pas
Re:Ha Ha, mine goes to 11 (Score:5, Insightful)
What you're missing is that the percentage of the general population that can consistently (a) remember a long password and (b) type it without a failure at least 50% of the time, is in the single digits. Remember, general population, not geeks.
I've expressed the opinion for several years now that password authentication is broken, and that we need to move to two-factor authentication schemes ASAP.
--Paul
Re:Ha Ha, mine goes to 11 (Score:5, Informative)
Screw the general population. I'm a geek and a 120+ WPM @ 98% accuracy typist to boot and I can't even enter our administrative password more than 50% of the time at work.
Re: (Score:2)
I think you need a real random source (as some device counting radioactive decay) to create the passwords in a secure manner.
Done. [fourmilab.ch]
What now?
Re: (Score:2)
All you need to do is use a unicode character set and it pretty much kills any local password cracking attempts.
Re: (Score:2)
Use your generator to make a 100 character password, then cut out chunks of it wherever you feel like and add a number or letter here and there until you have a password near the maximum password length for the site.
You don't need a truly random source to be unpredictable.
Re: (Score:2)
most of the password generators do have randomisation, usually asking the user to bash the keyboard or jiggle the mouse. How random and/or useful that turns out to be is debatable.
Re: (Score:2)
Is that your password or a recently erupted volcano?
Re:Ha Ha, mine goes to 11 (Score:5, Funny)
That's amazing. I've got the same combination on my luggage.
If someone gets your hashed password, you're done (Score:5, Insightful)
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.
Re:If someone gets your hashed password, you're do (Score:5, Interesting)
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 [wikipedia.org], PBKDF2 [wikipedia.org] or scrypt [tarsnap.com]. 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.
Re:If someone gets your hashed password, you're do (Score:5, Insightful)
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.
Re: (Score:2)
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
Re: (Score:3)
One of the first things he said was "It's impossible to have too much security, right?" The audience almost unanimously agreed. He said "Wrong!"
He said, "In NT,
Dunno if that helps (Score:2)
What about salting? (Score:3)
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?
Re: (Score:3, Informative)
Re: (Score:2)
The salt is stored in a relatively insecure manner. It needs to be because the system takes the salt, adds it to the password you supply, runs it through the hashing function and compares it with the stored hash.
Re: (Score:2)
You're missing the point. If a unique salt is used for each password, then you have to attack each password individually. If the same salt is used for each password, then when you compute a hash, you can compare it against all the hashes in the database at once.
Unless the attacker is targeting your account specifically, then yes, individually salted passwords help.
Re: (Score:2)
> Is my five letter password more secure if the salt is 15 characters long?
No. The salt helps against dictionary attacks. Normally, it is different for every user, but not secret. It does not help against brute-force attacks.
What does help, is adding more rounds to your key-derivation function (e.g. PBKDF2). Or choosing a longer password.
Re: (Score:2)
The crazy thing about salt is that it's always known by the attacker...
Who cares? (Score:4, Insightful)
Hooray, you can crack an NTLM [wikipedia.org] 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.
Re:Who cares? (Score:4, Informative)
Technically, MS *did* use a valid and acceptedly secure hash functions, DES and MD4. The problem is that, because of backwards compatibility across their 20-year product spans, they were not as vigilant in updating the protocols. Even when they *did* upgrade them, they went to MD5 (with NTLMv2) - which was again proced weak - but they continued to use the older protocol which allowed trivial attacks.
Which is why anyone "worth his salt" will laugh if you propose a crypto system which is supposed to last 20 years and is not flexible in its choice of component algorithms.
1Password FTW (Score:2)
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.
Re:1Password FTW (Score:5, Insightful)
Your shameless plug is correct, but for one problem:
When you use a fingerprint sensor, the traditional attack methods (brute forcing, social engineering, etc) still work. But you also add a new attack method, by generating a fake fingerprint from that coffee cup you threw into the trash that morning.
Needless to say, increasing the possible attack vectors decreases security, rather than increasing it.
Windows problem! (Score:4, Informative)
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).
Re: (Score:2)
Re: (Score:2)
Faulty Assumtions (Score:4, Insightful)
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...
Re: (Score:2)
If only... (Score:2)
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...
SmartCards (Score:2)
Big-O complexity, look it up (Score:2)
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 a
Re: (Score:2)
Is NTLM still in use? It's been deprecated for years - is it even enabled by default on recent versions of Windows?
Re: (Score:2)
This still does not eliminate the fact that each digit added increases the cracking time exponentially. In other words, use a longer password.
There's only so much entropy a human brain can memorize easily. If you try to make it easier to remember, by making it pronounceable, or even using words, that decreases entropy defeating the purpose of extending your password.
Dunno what solution there is when computers can brute force passwords longer than a human can memorize.
Re: (Score:2)
Uh how about KeyPass?
Re: (Score:2)
Then they can just brute force your KeePass passphrase.
And in other news (Score:5, Funny)
3m are going to introduce a larger post-it-note
Re: (Score:3)
http://www.post-it.com/wps/portal/3M/en_US/Post_It/Global/Home/Products/Easel_Pads/ [post-it.com]
3M: Innovative Technology for a Changing World!
Challenge respose is dead, almost. (Score:2)
NTLM? Please be serious... (Score:5, Insightful)
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.
No kidding (Score:5, Informative)
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.
NTLM? Seriously? (Score:2)
What kind of incompetent fool would still use such a pathetically weak password hashing scheme?
Here's a link to the original article (Score:5, Informative)
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 [wordpress.com], Vijay Devakumar. And here's Ivan Golubev [golubev.com], who wrote the cracking tool.
Still, ZDNet's advertisers thank you for the hits!
Re: (Score:3, Informative)
Go for length over complexity (Score:4, Informative)
This article spells it out:
http://www.baekdal.com/tips/password-security-usability [baekdal.com]
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.
Re: (Score:3)
Reminds me of the famous Bruce Schneier fact:
Most people use passwords. Some people use passphrases. Bruce Schneier uses an epic passpoem, detailing the lives and works of seven mythical Norse heroes.
Summary, article, and references all FUD. (Score:4, Informative)
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.
Re:So What? (Score:5, Informative)
Re: (Score:2, Informative)
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 net
Re: (Score:2)
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
Password Plus CAPTCHA helps (Score:4, Insightful)
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.
Re: (Score:2)
no need to change, 8 character using say 100 possible character password that isn't word or same as account name still can't be cracked by brute force attempts. Besides the challenge / response lag, and systems not allowing login for certain time after say 4 unsuccessful attempts, look at the math. That's only five attempts every five minutes or one attempt per minute allowed. That's 100 ^ 8 minutes for all possible combinations, or 10^16 minutes, or 2 x 10 ^ 10 years. The Sun would burn out first.
Re:Password Plus CAPTCHA helps (Score:5, Funny)
"The Sun would burn out first."
Especially if it's an old Ultra 5.
Re:Password Plus CAPTCHA helps (Score:5, Insightful)
Let's look at some alternative alternative math: that 3.3 billion passwords/sec were at http://www.golubev.com/files/ighashgpu/readme.htm [golubev.com]. Note that this is the speed for cracking MD5 passwords, which were deemed "almost ready to crack" a few years ago. Modern Linux systems all support sha256 and sha512 hashing; given that this tool is 1/3 slower for sha1 (aka "sha160"), one can guess that current sha2 (sha256/sha512) algorithms will be slower. It's also worth nothing that the algorithms supported by the tool mentioned in the article are *all* not supposed to be used as of 2009: http://csrc.nist.gov/groups/ST/hash/policy.html [nist.gov]; the tool doesn't currently even support the sha2 algorithms. The common algorithms which are currently supported (ie, md5) have been breakable in fractions of a second through rainbow tables for years anyway - which was NIST's point, IIRC.
I suppose I'll also note that the Ubuntu 11.04 system I'm typing this upon right now is configured out of the box to use sha512 hashing in /etc/shadow (check /etc/login.defs on most Linux systems, look for password strings which start with $6$). Assuming the use of PAM for anything important and passwords stored either in root-only shadow file or in an LDAP directory which does compare-only access or server-side hashing, and a secure transport such as current TLS, then this is a non-issue on a Unix system which hasn't already been compromised. It'd be easier and probably more effective, as usual, to socially engineer a password (or otherwise gain access through the human interface weak point) than to get password hashes and break them.
Re:Password Plus CAPTCHA helps (Score:5, Interesting)
Strictly speaking, NIST still allows the use of SHA-1 for password hashing. NIST says you shouldn't use SHA-1 for anything that requires collision resistance. Password hashing doesn't require collision resistance, it only requires preimage resistance. In fact, there's relatively little benefit to using SHA-256 or SHA-512 for password hashing, since they're not that much slower than SHA-1 and its not much harder to generate and store a SHA-2 rainbow table than a SHA-1 rainbow table.
The page you referenced is from 2006, and NIST has backed off on their warnings about SHA-1 a little bit. The collision attack on SHA-1 probably isn't as bad as it looked in 2006. The attack hasn't improved- some of the alleged improved attacks turned out to have errors in them. No one has ever found a collision using SHA-1. Some people aren't even sure the claimed collision attack even works, though the general agreement is that even if the specific attack outlined in Wang's paper doesn't work, there probably is a similar one that does work.
In the mid 2000's the cryptographic community just saw both of the widely used hash functions attacked- SHA-1 and MD5. There were a lot of people concerned that the attacks would soon be catastrophic. That certainly didn't come true with SHA-1, and its only partially true with MD5 (which still has decent preimage resistance).
Still, telling people to move to SHA-2 is good general-purpose advice. It can be tricky to determine when you need collision resistance and when preimage resistance will do.
Re: (Score:3)
"The common algorithms which are currently supported (ie, md5) have been breakable in fractions of a second through rainbow tables for years anyway - which was NIST's point, IIRC."
You must recall incorrectly, because a rainbow table is effective against ANY hash function, no matter how secure, although using salts (also known for some stupid reason as "nonces") can alleviate this weakness to a large degree.
In fact that is a big objection of mine to many of the things that have appeared in this topic today. A lot of nonsense has been bandied about.
For example, while certain cryptographic weaknesses have been found in MD5 and SHA1, those weaknesses are more theoretical than pract
Re: (Score:2, Insightful)
The quicker CAPTCHA dies the better.
Not only does it discriminate against machines (like it should) it discriminates against humans, too.
I long for the day when the Americans with Disabilities Act gets amended for the interbutt. You are an institution or you do commerce on the Web? You can no longer discriminate against the sight impaired ever again.
People see CAPTCHA as a magic wand for dealing with brute-force attacks and spam. It's not. If it was a pill for erectile dysfunction, the side effects woul
Re:Password Plus CAPTCHA helps (Score:5, Informative)
The quicker CAPTCHA dies the better.
Not only does it discriminate against machines (like it should) it discriminates against humans, too.
I long for the day when the Americans with Disabilities Act gets amended for the interbutt. You are an institution or you do commerce on the Web? You can no longer discriminate against the sight impaired ever again.
Most of the big name CAPTCHAs I've seen have an audio alternative, so what's the issue?
Re: (Score:3)
Someone who'se completely blind would most likely use a program called a screen reader (JAWS was a common example last time I really looked into this, probably others out there as well). This is just a program that does text-to-speech for on-screen content, including web pages.
A screen reader would "read" the images using their alt text. Assuming the sound button had alt text that made sense it'd be pretty simple to select it and hear the content of the captcha.
Re: (Score:3)
I'm surprised no one has circumvented CAPTCHA by examining the audio.
I assume you're being sarcastic, but for those playing along at home: http://search.theregister.co.uk/?q=audio+captchas [theregister.co.uk] and http://slashdot.org/tag/captcha [slashdot.org] list several successful attacks on audio CAPTCHAs...
Re: (Score:3, Funny)
...projectile diarrhea...
Wow, you discovered my Slashdot password. I've had it for several years, now I have to change it...
Re: (Score:3)
I'm an engineer, so in many ways, I am not stupid, but in other ways, I think I am. I think I may be worse at some types of CAPTCHAs than a machine. It gets pretty frustrating, really.
One CAPTCHA I did get correct recently required me to enter a greek letter (to access an English-speaking forum). I didn't know how to type that letter, but I successfully copied and pasted it from Wikipedia, and it told me I was correct. These things are getting awfully exciting.
Re: (Score:3)
There are devices that convert on-screen content into braille [wikipedia.org] that someone who was both blind and deaf could use to read. I haven't played with these but I'm assuming there's an associated input device. There's a whole range of assistive technology out there for people now. The modern Helen Keller would probably be hanging out on facebook.
Re: (Score:3)
Did you know that many blind people actually have jobs? Just down the hall from me is a purchasing agent who handles literally millions of dollars of purchase orders each year. He is blind. Guess how much business would get sent to a company such as yours.
Re: (Score:3)
It is easy to thwart this attack, require a password in addition to a one time use RSA SecurID. eBay, PayPal, WoW and several banks already use this method of authentication.
http://www.rsa.com/node.aspx?id=1156 [rsa.com]
Re: (Score:3, Informative)
Solution: Make a stronger password. [grc.com]
Re: (Score:3, Insightful)
Doesn't matter how strong a password is, xkcd [xkcd.com] have it covered.
Re: (Score:3)
It isn't fun to type; but "♯╪˧¾ᾥ▓►ﻸ" is relatively unlikely to fall easily. (Thanks Slashcode, still handlin
Re: (Score:3)
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 [oxforddictionaries.com] 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 ye
Re: (Score:3)
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.)
Re: (Score:3)
Re: (Score:2)
Yeah, I was thinking about doing that on my site in light of the gawker crack.
Logins are relatively rare events on the server, so I could do something like 1000 SHA-1's with a salt on each iteration. That'd mean
a) It'd take 1000 times longer to crack (obviously this is a constant war between me and the adversary)
b) If i build my own salting implementation on top of sha-1 I doubt I could end up with anything less secure than SHA1 but hopefully it'll require custom software to actually do the exploit.
Re: (Score:2)
Does anyone really use less than ten character passwords anymore?
Your bank. My bank. The nuclear reactor down the street. All sorts of folks.
Re: (Score:2)
Sure, IF we're talking about remote logins.
What about, say, a stolen laptop, how exactly will you enforce "1min/try" there...?
Re: (Score:2)
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.
Re: (Score:3)
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]
Re: (Score:2)
No it won't. Running the same hash multiple times does not make it better. that is not how crypto works. Besides that, that would make it incompatible with older NTLM systems...
The password needs to be strong enough. Acrtually in NT passwords can be 255 chars long. maybe there is even room for improvement [dilbert.com]
Re: (Score:2)
Re:long random passwords (Score:5, Informative)
It doesn't work like you think it does.
Basically, most modern password protection techniques work like this: they take a password, say "my nice password" and transform it into a hash, say :"uq10ajg901a0##". Now only the hash is stored on the system. There is no way to go from the hash to the password. Classical hash functions are MD4, MD5 and SHA1. NTLM users MD4. Linux mostly uses MD5. There are added niceties likes salt, etc. You can look these up if you want.
When users enter their password, they are hashed again, and the *hash* are compared, not the passwords. If you enter the right password, no matter whether this is a nice word or sentence or jumbled letters, the system lets you in.
Crackers simply assume that the *hash* is available. It is in fact very easy to get it if you have access to the console, both for Linux or Windows. They then generate any and all combination of letters, signs, symbols and so on as input as potential password, they compute their hash, and they compare it to the hashes they know. If there is a match, bingo, they have found the password.
So the upshot is it doesn't really matter what the input password look like as long as the crackers can generate it and compute their hash. If the crackers know that you have used only letters, however, they can cut down dramatically on the numbers passwords they have to generate and save time.
So in some sense you are right but not for the reason you mention.
Hope this helps.
just the opposite effect (Score:3)
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 i