Live data from Hacker News

A Really Good Article on How Easy it Is to Crack Passwords

schneier.com

31–40 of 76 posts

Re: A Really Good Article on How Easy it Is to Crack Passwords

#31

Passwords are broken and I really wish we would all move away from them. Persona is a nice idea with regards to privacy and control, but it's still a password that you need to remember, which can be cracked. Also, people generally don't use strong passwords. What irks me is that every OS in use today has support for strong cryptography and browser vendors could easily integrate that. We would no longer register for a…

And how do you access your identity from a device that isn't your own? I'm 100% with you, it would be a major step forward - but it's too inflexible for Joe & Jane.

I wouldn't mind it if I had to have my phone to access the identity. It would be a simple matter of integration to use the phone to grant a temporary authorization to an unknown device.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#32
post #26

I don't understand the difference between "momof3g8kids" and "tlpWENT2m". Why would the latter be more secure?

Actually, it's hard for a 9-character password to beat a 12-character password even though the latter has a larger alphabet/key-space (unless I've completely blown the analysis below, which was done before coffee :).

The first has a key-space of 36^12 (36 possible characters in each of 12 positions), or about 4.7e18. The second has a key-space of 62^9 (62 upper/lower case letters and digits in each of 9 possible locations), or about 1.4e16.

If, in addition to adding the uppercase letters, you added the possibility of needing to test symbols, such as ~`.,/:;!@#$%^&*-=_+ (another 19 symbols), and changed the latter password to "tlpW#NT2m", then the searchable key-space for all 9-character passwords becomes 81^9, or about 1.5e17.

RE-EDIT: Sorry. I should have read the article first. I'm not sure why the latter would be more secure. Obviously "WENT" would be in a dictionary, so I'd think that "tlpWENT2m" would fall to a combinator attack very quickly, too.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#34
post #17

Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down . To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effec…

I think you need to analyze the risks more specifically.

You should rate-limit login attempts on the live site. Even allowing only one login attempt per second kills any brute-forcing attack if your passwords have even mediocre complexity.

Password cracking is only really a threat is the bad guys get your database. And if they do, it's not much more difficult to crack two passwords than one.

The point of true two-factor is that the second "password" which comes from the device is never stored in your DB, so it cannot be cracked. That is not true of your approach.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#35
post #17

Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down . To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effec…

Except everyone will lose their passphrase. Everyone.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#36
post #27

Earlier quoted context omitted.

What makes you think he misunderstands it? For the cracker it's not about entropy per se, it's a game to come up with algorithms that crack more passwords for less compute power. The XKCD comic got a lot of mindshare so it makes sense to target algorithms towards that type of password. I think Schneier's suggestion of reducing it to the first letter of each word is vastly preferable because it packs the majority of e…

How would something attack Diceware? There's a list of 7776 words, everyone knows what words are on the list. I suspect that sometimes people re-roll because they don't like a word or don't think they'll remember it. But I don't that that makes much difference.

> I suspect that sometimes people re-roll because they don't like a word or don't think they'll remember it.

This is strongly discouraged, and it does matter. The words are supposed to be random, but re-rolling makes them not random.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#37
post #21

The Ars article seemed totally irrelevant to me since it used MD5?

The cracking technique discussed is dictionary plus some common substitutions. So the hashing algorithm is not very important. You would loose some factor of speed, but the 1000 most common passwords times 10 common substitutions, perhaps with 100 postfixes is still only 1 million hashes. And you would crack with these some non negligible fraction of the passwords in an unsalted database in probably under a minute. ( If the passwords are salted in the db, then you need a minute per hash, so assuming that you crack a few percent of the hashes you try, then you expect one password in under two hours even with modern password hashes.)

Re: A Really Good Article on How Easy it Is to Crack Passwords

#38
post #17

Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down . To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effec…

I think you need to analyze the risks more specifically. You should rate-limit login attempts on the live site. Even allowing only one login attempt per second kills any brute-forcing attack if your passwords have even mediocre complexity. Password cracking is only really a threat is the bad guys get your database. And if they do, it's not much more difficult to crack two passwords than one. The point of true two-fac…

Yes you are right that it is not 'true' two-factor authentication. It would certainly be more secure if all my users were able and willing to use something like Google Authenticator. However, I suspect that most of my users (who are not especially computer literate) would prefer the simplicity of writing down 4 words over having to install and configure an two-factor app on their phone.

You say, "it's not much more difficult to crack two passwords than one" but I don't see how that is the case if the second password is four words chosen at random from a dictionary of say 5000 words. Such a password is far more difficult to crack than the average password chosen by the average user. Having a second passphrase generated by a computer also eliminates the problem of users re-using the same password between sites, or choosing "letmein" or "password1" as a password.

Re: A Really Good Article on How Easy it Is to Crack Passwords

#39
post #2

Remember, security against cracking is a combination of password strength and key derivation function strength . Nothing will save you if your password is "password". Not much will save you if your password is hashed with MD5. But scrypt can be over 100,000,000 time stronger than MD5 -- so if you're using scrypt you can afford to use a password which is 100,000,000 times weaker. "jdtwbv" hashed using scrypt is strong…

""jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5"

Is it? I'm not sure.

for the first one you're using lowercase letters (and digits, I'm giving you that 'free')

For the first one we have 36^6 For the second one (all printables) 100^9

Relation between them: ~ 459,393,658. If you're saying scrypt is 100M times better, in this case the second one is safer

And the relation is important but less as computers get faster. Option B may take 1Mi times as long as Option A but if Option A takes 1 microsecond, there goes your Option B as well

Re: A Really Good Article on How Easy it Is to Crack Passwords

#40
post #17

Why not force the user to have strong login credentials? I'm creating an online system that will store users' sensitive financial data. When setting up an account, the user will have to choose a password as normal, but will also be given a passphrase of the form "correct horse battery staple" that they must write down . To log in, the user will need to enter (a) username; (b) password; and (c) passphrase. It is effec…

Another issue with this is it breaks password managers, including the built-in browser password storage. While you might say that's a Good Thing for security, it's not something you could easily pull off as a startup. Due to lock-in effects, people have to deal with all manner of usability hell from their bank, but the same logic doesn't apply to startups. Not that your idea is usability hell, but you probably don't…

> I think adding a few characters to the minimum password would be equally secure

Do you mean saying to the user, "your password must be at least 12 characters long"? That would just result in the user adding "12345" to the end of their standard password. Still seems much easier to crack than 4 random words.

> Also, 2FA might be easier than you think using a service like Twilio.

It might be easy for me to set up, but for my users (who are mostly non-technical) it is still relatively painful to install and set up a two-factor authentication app. I think most of my users would prefer the write-down-four-words option, even if it is a little less secure.

> you probably don't want to make it any harder than it needs to be

OK, so the question is, "does it need to be harder than the standard login form of username and password field?". Since my system deals with sensitive financial data, and given the problems with allowing users to pick their own password, I would say the answer is "Yes"

Post reply on HN