We should stop calling them passwords to users, seeing as the best passwords are the concatenation of several non-words.
Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
41–50 of 90 posts
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#42Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password. If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilitie…
We can't even get people to dump IE6. How the hell are we going to get them to use longer passwords, and change them every year? Scrypt is better than longer passwords because it's actually possible to implement in practice.
People use IE6 because of external forces. You can add longer passwords to your application and still make it work with IE6.
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#43We should stop calling them pass words to users, seeing as the best passwords are the concatenation of several non-words.
I believe we made a misstep with the password. I learned a long time ago that how you frame something for the user changes how they will interact with it. A common example I refer to is a small textarea on a website, and some clients wanting to see that textarea larger to encourage their users to write more in the box, or witnessing a user stopping and editing their post to frame it inside of the available area without going over.
The same with passwords, they imply a word. A much better solution is a pass phrase. As far as the system is concerned, functionally identical. But to the human mind, a completely different animal. A word is a word, but a phrase is limitless. With proper punctuation and capitalization, it has everything that makes a good password good: A-z, symbols, length. Except, being a phrase, it has an edge to a long complex password: you can remember it. A phrase has a beginning, middle, and an end.
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#44Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password. If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilitie…
We can't even get people to dump IE6. How the hell are we going to get them to use longer passwords, and change them every year? Scrypt is better than longer passwords because it's actually possible to implement in practice.
> How the hell are we going to get them to use longer passwords, and change them every year?
You merely require them to use longer passwords, and require them to change them every year. My university does this. They require a minimum of 8 characters, and they require that we change our password every 3 months or we can't log in.
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#45This is insane for password cracking. I've been trying to get Pyrit working on the Centos image but have been having trouble compiling it. An 8 node cluster with Teslas is going to bring WPA-PSK cracking down to where WEP was a few years back for those who can afford it. This is an incredibly disruptive thing for Amazon to do. They've just brought near-government grade crypto-breaking capabilities to the mass market.
> I've been trying to get Pyrit working on the Centos image but have been having trouble compiling it. An 8 node cluster with Teslas is going to bring WPA-PSK cracking down to where WEP was a few years back for those who can afford it.
Are there legitimate uses for password cracking or is this about getting access to other people's accounts?
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#46Earlier quoted context omitted.
They've just brought near-government grade crypto-breaking capabilities to the mass market. No, they really haven't. Near-government grade KDF-cracking capabilities will be when Amazon announces FPGA Compute instances.
Last time I checked, GPU processing has a better-bang-for-the-buck than FPGA processing, and the gap continues to widen.
I suspect the NSA doesn't care too much about bang-for-buck. 22nm FPGA's [1] seem like they would work pretty well.
In an interesting twist, The Register claims that Achronix's decision to use Intel was driven in part by national security considerations. We've reported extensively on the idea that chips fabbed overseas in insecure facilities could contain hidden kill switches or backdoors that would let an opponent cripple the US military, and Achronix allegedly wants to be able to sweeten its pitch to military customers by offering a home-grown solution.
[1] http://arstechnica.com/business/news/2010/11/intel-shifts-st...
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#47First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is still usually a singel command, and WAY more secure than simple shaX or mdX, as it eliminates the risk of prefix/postfix attacks. Adding the salt makes dictionaries pretty irrelevant (as long as each install has a unique salt). I mean GEEZ; even php does it no…
An HMAC is a message authentication code, not a salted hash. It allows you to send a message over an insecure link and verify, by providing the secret key, that the message (and hash) was not tampered with.
Also, a salted hash is not a particularly good storage mechanism, ranking only above cleartext and naively-hashed storage. Once someone discovers the salt, then it's fairly easy to attack the password database in the same way that you'd attack an unsalted hash -- make a list of all possible passwords, hash them, and see what matches. Machines like the one mentioned in the article can make trillions of these in a second. The problem with hashes for protecting passwords is that they can be calculated very quickly; good for ensuring that every packet on your VPN arrived without errors, bad for ensuring that a bad guy can't make a list of passwords, hash them, and check the hashes against your database.
The best password storage mechanism is via the use of a "slow" hash function like bcrypt or scrypt. You set these up so that it takes a full second of CPU time to generate the hash from the message. Then instead of trying trillions of passwords a second, the attacker can only try one!
If you're using Perl, use Authen::Passphrase. It's a module that lets you easily use bcrypt for new passwords but your old method for older passwords. With an API like that, there's no excuse for endangering your users by using salted hashes!
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#48First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is still usually a singel command, and WAY more secure than simple shaX or mdX, as it eliminates the risk of prefix/postfix attacks. Adding the salt makes dictionaries pretty irrelevant (as long as each install has a unique salt). I mean GEEZ; even php does it no…
Shouldn't the nonce be different for each password rather than for each install (I take it that by "install" you mean a server or an application installation)?
Nonce-per-password is used in BCrypt and while I don't know much about security, that's the vibe I'm getting from the folks who do.
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#49Anybody know how tarsnap's scrypt lines up against HMAC-based key derivation[1]? In particular, let's say I used the HMAC of the password as the bases for the HKDF?
Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances
#50This is insane for password cracking. I've been trying to get Pyrit working on the Centos image but have been having trouble compiling it. An 8 node cluster with Teslas is going to bring WPA-PSK cracking down to where WEP was a few years back for those who can afford it. This is an incredibly disruptive thing for Amazon to do. They've just brought near-government grade crypto-breaking capabilities to the mass market.
> I've been trying to get Pyrit working on the Centos image but have been having trouble compiling it. An 8 node cluster with Teslas is going to bring WPA-PSK cracking down to where WEP was a few years back for those who can afford it. Are there legitimate uses for password cracking or is this about getting access to other people's accounts?
At my day job we mostly do penetration testing and incident response. Sometimes we need to crack passwords so we have these huge files called rainbow tables that can be used to look up a very high percentage of possible passwords for given algorithms, but aren't infallible and take time to search.
We sometimes crack passwords to do a password strength audit. Sometimes dictionaries aren't really enough (as someone might have chosen an obvious word in another language) so it's easier to just crack the passwords, automate analysis of the obvious and then scan through anything left behind.
WPA-PSK cracking is particularly useful in the UK Local Government sector, where local government in most cases needs to have an annual penetration test, often including their wireless networks. A lot choose WPA-PSK because it doesn't mean spending money on a full-blown wifi network.
The other thing we use password cracking for is when we do incident response work. Sometimes people encrypt things like documents or use PGP containers. This isn't quite making PGP cracking feasible, but certainly the majority of encrypted word documents should be doable with this.