GPU - ie Radeon 5770 makes even 15 character password unsafe to brute force!

[LxMxFxD4]

Isn't there an easy solution? Require 1 or 2 seconds between login attempts.

This is why everyone should get a security+ cert. I appreciate that people don't understand handshakes and certificates and many other advanced topics, but really?

Passwords are like house locks. Anyone can break in at any time, so dont keep your valuable shit in places where people get get to it. Passwords like locks, are there to keep the honest man honest. Theres a reason why the security government agencies aren't connected to the interwebz.

 

[HumblePie]

This is why everyone should get a security+ cert. I appreciate that people don't understand handshakes and certificates and many other advanced topics, but really?

Passwords are like house locks. Anyone can break in at any time, so dont keep your valuable shit in places where people get get to it. Passwords like locks, are there to keep the honest man honest. Theres a reason why the security government agencies aren't connected to the interwebz.

Also token + passwords = impossible to crack. As the tokens are constantly changing every 10 seconds or so.

 

[Golgatha]

Steve Gibson wrote a great article/sample program for this exact problem. Check it out here:

http://www.grc.com/haystack.htm

Basically, it doesn't matter how complicated you password is. It only needs to have a non-dictionary word that includes a lowercase letter, an uppercase letter, a number and a symbol, and then be as long as possible. You could even use a memorable sequence as long as it includes all of those factors.

What's awesome is that my bank doesn't allow special characters to be used in your password.

 

[evilspoons]

Also token + passwords = impossible to crack. As the tokens are constantly changing every 10 seconds or so.

Only the very foolish person says "impossible". The correct phrase is "much harder to crack".

See the RSA / Lockeed-Martin thing.

 

[Voo]

Only the very foolish person says "impossible". The correct phrase is "much harder to crack".

If you're capable of breaking a state of the art cryptographic hash (and really NTLM hasn't been part of that group for as long as I can remember) that uses salts and non trivial passwords I'll congratulate you


The real news here is to stop using outdated hashfunctions. Because let's try how far the Radeon 5770 would've gotten when bruteforcing a SHA512 hash. Since the number was used in the article let's assume 3.3billion pw/second tried. SHA-512 has a 512hash - the birthday paradox means we only have to try 2^(512/2) hashes. Which means we would only need: 9.2*10^59 years. For comparison our universe is about 13.75*10^9 years old.

So to solve this problem "only" in that time we'd have to try about 10^50 more passwords every second.. let's hope that moore's law starts to pick up the pace a bit

 

[pcm81]

This is why i use the exact value of graham number as my passwords.

 

[Voo]

This is why everyone should get a security+ cert. I appreciate that people don't understand handshakes and certificates and many other advanced topics, but really?

Passwords are like house locks. Anyone can break in at any time, so dont keep your valuable shit in places where people get get to it. Passwords like locks, are there to keep the honest man honest. Theres a reason why the security government agencies aren't connected to the interwebz.

You're claiming anyone can break a SHA-512 or another modern secure hash (with other usual precautions)? Ah yes - maybe you should really take a refresher.

There are reasons though why timeouts aren't often a good solution (if it's a local password nobody stops the attacker from using different software; if it's a server you just enabled a simple DDOS attack)..

 

[Zensal]

What's awesome is that my bank doesn't allow special characters to be used in your password.

I love those. Maybe the next feature they'll add is a max of 8 characters.

 

[Lonbjerg]

I love those. Maybe the next feature they'll add is a max of 8 characters.

They did one better in Denmark, we got this national eletronic login to everything (NemID) from your netbank to IRS.

It's using none case sensitve PW's....the horror.

 

[StrangerGuy]

A half-decent password system is gonna let you input a billion combinations a second into it without any blocking. Right?

 

[Zargon]

This is why everyone should get a security+ cert. I appreciate that people don't understand handshakes and certificates and many other advanced topics, but really?

LOL wut?

come back to reality sometime

 

[evilspoons]

I love those. Maybe the next feature they'll add is a max of 8 characters.

My bank has a maximum of 8 characters and no special symbols. I'm not even making this shit up, they have a less secure login system than my friggin' Neopets account from 1998.

 

[Mark R]

The real news here is to stop using outdated hashfunctions. Because let's try how far the Radeon 5770 would've gotten when bruteforcing a SHA512 hash. Since the number was used in the article let's assume 3.3billion pw/second tried. SHA-512 has a 512hash - the birthday paradox means we only have to try 2^(512/2) hashes. Which means we would only need: 9.2*10^59 years. For comparison our universe is about 13.75*10^9 years old.

So to solve this problem "only" in that time we'd have to try about 10^50 more passwords every second.. let's hope that moore's law starts to pick up the pace a bit

Ideally, you wouldn't use cryptographic hashes. Cryptographic hashes are designed to be simple to calculate, because they may be used on large messages (where performance may be important), and the most important priority is to ensure a good resistance to collisions. Irreversibility is important, but less so.

Protection of passwords requires a slightly different solution. You don't need high performance, because passwords only only used infrequently. You don't need good resistance to collisions. But, above all else, you need irreversibility.

The development of sophisticated brute-force techniques such as GPU accelerated systems, rainbow tables, etc. makes achieving irreversibility very difficult. However, you can dramatically improve things by designing a hash that is very time consuming and difficult to calculate (e.g. requires large amounts of RAM, and large amounts of serial calculations, that make paralleling and optimisation of the algorithm difficult).

As a result, there are special password hashing algorithms available such as pbkdf1, bcrypt or scrypt which are designed to be very resource intensive to compute - taking up to 3 second per key on a modern PC, and/or using a significant amount of RAM (many MB). By making the algorithm extremely RAM hungry, it makes it impractical to run it on massively parallel processors like GPUs, and impractical to build FPGAs or dedicated cracking ASICs.

 

[Phynaz]

Also token + passwords = impossible to crack. As the tokens are constantly changing every 10 seconds or so.

SecurID is compromised

 

[Ghiddy]

It doesn't work like that.

I always wondered about this. Why doesn't it work like that?

At work 3 consecutive failed logins in a 15 minute span will lock your account for at least a half hour. How can a brute force system work in situations like that? I'm sure there's an answer that I'm not aware of, which is why I'm asking.

 

[Mopetar]

A half-decent password system is gonna let you input a billion combinations a second into it without any blocking. Right?

You're still not understanding how this works. The hackers don't even bother attempting to input the password until they already know what that password actually is. At that point, they only possible way for it to look suspicious is if they're sending the login request from an IP that has a statistically high rate of hacking attempts.

Basically what happens is that a hacker will get a user database that stores at the bare minimum user names and passwords, but may also contain other user details such as full name, address, email address, account settings, etc. Once they've done this they'll probably start comparing the password hashes against some pre-generated rainbow tables for different hash functions to see if the site is just using common hash algorithms without any salting. It only takes one bad password to give away the correct algorithm. Once they have this, they can start a brute force attack against any stronger password.

Eventually they'll be able to crack any password and then have both a user name and password. At this point they can log in to the site using your own credentials. This is the first time that they actually make a login request. If they also have an email address, they'll probably try getting into that as well since most people use the same password for multiple sites. They might also try other popular sites as well.

 

[Mark R]

I always wondered about this. Why doesn't it work like that?

At work 3 consecutive failed logins in a 15 minute span will lock your account for at least a half hour. How can a brute force system work in situations like that? I'm sure there's an answer that I'm not aware of, which is why I'm asking.

If a hacker steals the user/password file/database off the server, then they can have as many attempts at finding the passwords as they like. Once they have the passwords, they can actually login to the server legitimately, giving them a lot more leeway in doing mischevious stuff.

The passwords, themselves, aren't usually saved in the password file (*) - instead a 'hash' is stored. A hash is a bit like encryption, in that it turns a readable message into gibberish. But, unlike an encrypted message, it can't be decrypted. However, if you can randomly generate billions or trillions of passwords, and calculate the hashes, you can check the password file to see if any match. For popular types of 'hash' there are even dictionary available, where people have precalculated the hashes for common password - you just take the hash, and lookup the password.

There are programs available that will take a password file, and use this brute force technique to attempt to retrieve the actual passwords for all the users.

(*) Of course, some programmers or sys admins are totally inept, and do simply put the passwords in the password file/database. In which case, a hacker that gets hold of the password file will be thinking all their Christmases came at once. However, the hash method is the recommended method, because with complicated and long passwords - and a good quality hash - it simply isn't practical to brute force it.

 

[pcm81]

I always wondered about this. Why doesn't it work like that?

At work 3 consecutive failed logins in a 15 minute span will lock your account for at least a half hour. How can a brute force system work in situations like that? I'm sure there's an answer that I'm not aware of, which is why I'm asking.

Ok, imagine a web page which logs you in. Imagine a hacker who knows user ids, but not passwords.
Now the hacker blindly tries all possible passwords, and all accounts get locked, since hacker tried 4 passwords per user ID.

You will say, wait, hacker does not know user IDs.
I say, hacker tries all possible combinations of letters+numbers for user IDs, each one 4 times to lock any collisions. With 100,000 attempts per second, hacker can lock 1,000,000 variations of user accounts in 40 seconds. 60,000,000 in under an hour.

You would need to block login attempts from hckers IP, not lock the account. Hacker writes a script to jump proxies every 5 seconds... you are defeated yet again...

 

[Voo]

You would need to block login attempts from hckers IP, not lock the account. Hacker writes a script to jump proxies every 5 seconds... you are defeated yet again...

That'd be a bit problematic unless you can find 10k or more proxies, but why if you can just as easily fake the header when sending the request?

SecurID is compromised

Huh huh. Obviously everyone here is talking about not compromised systems. Because otherwise every solution is by definition broken. How should any solution protecting you from logging in with the correct credentials (whatever those may be - other out of band solutions use the users phone, but hey I can steal that as well) work? (the usual problem - the only absolutely secure program is one that doesn't do anything..)

 

[Ghiddy]

Ok, imagine a web page which logs you in. Imagine a hacker who knows user ids, but not passwords.
Now the hacker blindly tries all possible passwords, and all accounts get locked, since hacker tried 4 passwords per user ID.

You will say, wait, hacker does not know user IDs.
I say, hacker tries all possible combinations of letters+numbers for user IDs, each one 4 times to lock any collisions. With 100,000 attempts per second, hacker can lock 1,000,000 variations of user accounts in 40 seconds. 60,000,000 in under an hour.

You would need to block login attempts from hckers IP, not lock the account. Hacker writes a script to jump proxies every 5 seconds... you are defeated yet again...

OK, so that could theoretically work against a website (though I think most sites worth breaking into SHOULD have rate limiting for failed login attempts from the same IP address).

But my original thinking was correct when it comes to NT passwords, right? You can't check all the combos on an NT password because of the account locking right?

 

[Voo]

OK, so that could theoretically work against a website (though I think most sites worth breaking into SHOULD have rate limiting for failed login attempts from the same IP address).

But my original thinking was correct when it comes to NT passwords, right? You can't check all the combos on an NT password because of the account locking right?

For servers we have the DOS problem.

For client side encryption the problem is as follows: Nobody forces you to use the NT login manager - just write your own code that doesn't have the timeout and use that (which is feasible and actually done for windows)

 

[Mark R]

But my original thinking was correct when it comes to NT passwords, right? You can't check all the combos on an NT password because of the account locking right?

Correct. However, if you are able to boot the NT box off a boot CD or memory stick, you can copy the password file off the hard drive.

Once you have the password file, you simply take it to another computer, where you can use a cracking program to test billions of passwords per second against the password file. Once you have the passwords, you can log into the NT box.

This can work against websites too - e.g. if the login data is stored in a database, and if there is a bug in the webapp, you can potentially get the web site to serve up the login data. Once you have that you can crack it at your convenience.

 

[Mark R]

For servers we have the DOS problem.

Which windows has a solution to, if you want to use it.

Windows does not mandate locking the account after an excessive number of incorrect logins. However, what NT servers will do, is gradually take longer and longer to verify individual passwords. So after about 3 or 4 wrong attempts, the server will start taking 10-15 seconds to verify the attempts. This will slow the attacker down to a point where attacks are no longer feasible, but still allow legitimate users to log in.

 

[raasco]

http://www.passwordcard.org/en

 

[Mopetar]

Ok, imagine a web page which logs you in. Imagine a hacker who knows user ids, but not passwords.
Now the hacker blindly tries all possible passwords, and all accounts get locked, since hacker tried 4 passwords per user ID.

You will say, wait, hacker does not know user IDs.
I say, hacker tries all possible combinations of letters+numbers for user IDs, each one 4 times to lock any collisions. With 100,000 attempts per second, hacker can lock 1,000,000 variations of user accounts in 40 seconds. 60,000,000 in under an hour.

You would need to block login attempts from hckers IP, not lock the account. Hacker writes a script to jump proxies every 5 seconds... you are defeated yet again...

There's no point in any hacker bothering to do this. What you've described is just going to most likely DDOS the site, which hackers can do just by flooding the site with traffic. Considering that if the server is taken down by the DOS attack, it really won't matter if someone has their account locked for some small amount of time as they can't access the site in the first place.