[pfalke]

As a non-infosec guy, could someone shed more light on the implications for end users?

I get that the combination of password reuse, short passwords and the fact that some services store passwords in plain text or as MD5 hashes makes it easy to break into accounts once a single service is compromised.

So my takeaway is not to use longer passwords, but to use a password manager and have unique passwords for every service. My current setup is 8 character passwords for online services (easier to occasionally type in manually).

Am I running a risk by not using 12 character passwords?

[bradleyjg]

In order of importance:

1) Don't use a really bad password like 'password'.

This one is the most important because it might allow an attacker to compromise your accounts online--that is without compromising the site itself.

2) Use a different password for each site.

This one is important because you don't want a compromise of smallvillelittleleague.org, which stores its passwords in plaintext, to mean that an attacker now has access to your banking accounts.

3) Use 2-factor on high importance / risk websites.

4) Use very strong passwords everywhere (i.e. long randomly generated).

If you've done 1-3 above the scenario where having a very strong password over a medium strength password is of concrete benefit is fairly narrow. It requires that the attacker get a website's password hashes, that the hash used be a fairly weak one, but that the website not be totally owned (because if it was then there's no additional benefit to having your site specific password).

All IMO of course.

[strictnein]

> 4) Use very strong passwords everywhere (i.e. long randomly generated).

You can also go the route of using passwords like:

   MyEmailIsFromGmail!
   or
   HackerNews?MoreLikeSlackerNews

[EvgeniyZh]

Note that HackerNews?MoreLikeSlackerNews has much less entropy than j-9yh`qw#j54-JIR$

[strictnein]

Sure, but having to type that in will cause an aneurysm.

[EvgeniyZh]

That's why password managers exist

[dahart]

I'm personally convinced 8 chars is now too short to be safe, and I suspect real attacks are generally much faster than 8 hours for a password of that length.

Using a password manager to generate random passwords you get a way to be impervious to dictionary attacks, in addition to being able to generate and manage longer passwords. I'm generally using 20 char passwords, and I'd turn it up further if there weren't so many stupid websites that limit the max length of passwords to 20 characters.

For passwords I need to type, especially if I need them occasionally on a touch screen tablet, I'll use a long all-lowercase letters password. Some of them have a 'make pronounceable' option as well that gives random syllables and makes typing a 20 char password easier than typing an 8 char password of completely random characters. 20 chars of lowercase alpha is a lot more secure than 8 chars of mixed-case alphanumeric and punctuation.

[tracker1]

Yeah... I feel if you're limiting input that limit should at LEAST be 64-100 characters or more. Then, since you're hashing anyways, I wouldn't worry too much about limits (other than practical check times, for creation complexity requirements, etc).

The other side is to use a fairly expensive hash, and methods to mitigate/reduce use of a login system as a DDOS vector... having the system, and database used for authentication separate from your actual application is a good start, as is exponential backoff on bad passwords by IP and username.

Moving to a separate "auth" domain that returns a signed or encrypted token, and having that in isolation won't stop your processes from running if you get too many requests for auth at once. Having an exponential and random wait before returning from a failed login is another. Keeping track of IP/user requests in an N minute block is also helpful.

token re-auth may be on the auth domain, or the actual service domain, so that can be different.

[pfalke]

Agreed that long passwords are generally better.

For online services (e.g., HackerNews), what's the scenario where an attacker cracks an 8 character password in 8 hours? I assume the attacker would need to download a copy of the service's password store and in that case the service has been hacked to a degree that the attacker won't need to crack passwords anymore.

[ThomasGeek]

Password managers are good but long passwords and password managers are better. If we are assuming MD5 then yes an 8 character password is not secure if someone is targeting you as it would take 10 hours to crack. If someone has a entire database of users let's say 50,000 users all with 8 character passwords then that would take 57 years to crack every password, so you may or may not be in the unlucky few that are at the top of the list. Also as GPUs get more powerful that time is going to come further down and you will be more at risk. Personally I use longer than 12 character passwords with a password manager, the inconvenience of having to type it in manually once or twice is not really that much greater than an 8 or 12 character long password.

[Tostino]

That 57 years is assuming they're storing their passwords MD5 hashed, with a salt (hah, i'm sure they thought of that if they're using MD5), and using the least efficient method possible to crack the passwords.

[tracker1]

It also assumes only a single system... not a cluster of several hundred or thousands. It also assumes no weaknesses in the algorithm itself that may be mitigated.