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.
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:
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.
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.
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.
Comments
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:
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.
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.