Skip to content

Comment on Strong Passwords

Comments

Having worked in IT, this is the kind of "guide" that I hate. It's theoretically correct, but wildly impractical and therefore not useful at all.

Do not let perfect be the enemy of good. Right now, people's password hygiene is not even "good".

Some specific criticisms:

At a bare minimum you should be using a unique 32 character random alphanumeric on every website or service that you use.

Sometimes you have to type in a password, even if you use a password manager. Maybe you are using a public computer. 32 character passwords are laughable. NIST recommends 80 bits, that's ~14 characters. Entirely sufficient.

Do not use online password services

If it means you're using different, reasonably strong passwords for all your accounts instead of just one password shared with everything, then PLEASE DO use an online password service. You will be vastly more secure.

Getting "normal" people to use good passwords means their password manager has to be super easy to use. LastPass is fine. 1Password is fine. Hell, even writing your passwords down in a book is fine, as long as you look after the book.

Infosec has struggled with 'good is better than perfect' - where good advice that is practical for most people is criticized for not being perfect practice that is often impractical.

Thankfully, now that there is a lot more public awareness of infosec practices - driven in large part by there seemingly being a big infosec story every week - a lot of the best practices advice has been loosened towards the more practical.

In terms of password management, I agree with you completely - the default advice should be to use an online password manager. I've got my partner and most of my family using Dashlane and with near 100% unique password compliance.

That type of adoption with regular users would never have happen had I stuck to "keepass, diceware and 32 character unique passwords" level advice.

I agree. Moving the needle is more important than puritanism.

I think encouraging longer passwords is a good idea. Even if 14 characters is suitable today in 2016, as computers get faster it will soon not be adequate.

By encouraging different password habits, people will be better prepared for the future.

I have to question your expertise on this matter since you suggest writing passwords down in a book, as well as using online password databases, both are terrible ideas.

Passwords significantly longer than 14 characters will never really be practical. Users hate typing them in. Password managers will never be ubiquitous. This is why the "pass phrase" has never really caught on and replaced the "password".

But I don't believe this is really a problem. As computers get faster, hashing can get slower. There is no upper limit on hash complexity.

Edit: This is your guide, isn't it? It would be ethical for you to disclose that, given that it has an advert for your business at the bottom.

And we'll never need more than 64kb of RAM too.

It was not many years ago when strong 8 character passwords were completely suitable. So respectfully I think your statements are false.

One of the reasons the guide recommends Keepass is that it eliminates the need to type in passwords completely. Even in the rare case of poorly designed apps that block pasting, the auto-type capability works around that.

A fully random 8 character password, using uppercase, lowercase, and digits, should still be OK today if hashed with bcrypt (or similar or stronger scheme).

I searched around and found someone posted some hashcat-ocl benchmarks done with a Titan X about a year ago, and it could do 14440 bcrypt hashes per second. So let's calculate how many "Titan X * days" are required to brute-force such a completely random password using that character set:

    >>> (26 + 26 + 10) ** 8 / 14440 / 3600 / 24
    175005
If you assume the best GPU today is twice as fast, and that someone has 8 of them in a rig, that's still 10 thousand days to search all possibilities, which means 5 thousand days on average until the hash collision is found.

For a typical user account, 5 thousand days of crunching by 8 of the most powerful GPUs on the market, is pretty good.

I personally go for 9 or 10 character passwords that include some symbols too, but are a bit less random ;)

Anyway, the biggest factor is to use a unique password for every account, because you can't guarantee that none of the websites you use didn't totally fuck up and accidentally put the original password somewhere, nor can you guarantee that they won't be hacked to the extent that the passwords are intercepted during sign-in.

A fully random 8 character password

If you were given a list a human generated passwords and computer generated passwords, you could spot the difference immediately. Passwords are not random, and crackers take this into account. Most passwords are letters with a stray symbol here and there. More advanced password crackers take a dictionary of base words and use Markov chains of passwords to try.

This greatly reduces the search space and the eon-long searches start looking more in reach.

That's true - human chosen passwords are vulnerable to more clever non-brute-force attacks. This effect is rather different than the interplay between computer power and hashing schemes though. (Thus my strong qualifications about fully-random :)

Apples and oranges, imo. There is no difference in practicality or usability between 64k of RAM and a gigabyte. There is a big difference in both as you make passwords longer and more random. This is not a commentary on whether that's a good or bad idea :).

For the people who recommend password managers, I do wonder why the password manager site is deemed to be more trustworthy than all the presumably untrustworthy (i.e. with respect to secure practices) sites, the passwords to which are stored in it?

For the most part, because they pay attention to it, and because their business success depends much more critically on it. Look at the Lastpass hacks -- they were breached, but there was approximately no impact to their users, because their security model for password storage is sane. In contrast, consider, say, the Adobe breach, which leaked 150M passwords that in many cases could be matched to their cleartext quite trivially.

Most password managers worth considering do not store the users' passwords unencrypted (or ever touch them unencrypted). Instead, they use a master password known only to the user, followed by a computationally expensive key derivation (PBKDF2 or similar) to create an encryption key, and encrypt the passwords with that. They then use a different derivation path to handle authenticating the user to their servers.

It's a very reasonable architecture unless you're on the extreme end of paranoia. Notably, I have about four passwords I don't store in my password manager. But I'm very happy trusting it with my bank and financial stuff.

The reality is that getting people to use a good password manager with randomly-generated passwords, regularly, on all of their accounts and devices -- with 2FA for the important stuff -- is far more important than the slight extra security risks from using the online components of the good services.

I think the point is that hashing algorithms can be adjusted to scale with the increase in processing speed.

Exactly. It is made easier if you store the hashing algorithm and parameters used against each user record. As you increase the parameters, or change the algorithm, you can update user passwords on login.

Have you ever dealt with actual non-techies on this?

In a week we learn, via HN, of the Last FM top 50 passwords (usual suspects, no surprises), and that 50% click on any link sent them moving the needle at all is more important than getting it to great.

I've come across many intelligent, successful, professionals who still reuse passwords, who still use child's name + random number for important things. Is using a book or online service a terrible idea compared to using steve36 for his domain registrar? What you call terrible at least moves the needle away from zero.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.