Strong Passwords
strongpassword.us
strongpassword.us
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.
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.
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.
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?
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 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
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.
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.
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.
puts ((rand * 1_000_000_000).to_i.to_s + \
("a".."z").to_a.sample(10).join + \
("A".."Z").to_a.sample(10).join + "_")
You can save your passwords in a gpg'd text file if you want, though it usually doesn't matter that much. Just store them in chrome and use two-factor. If you get logged out just password reset to your email.
$ openssl rand -base64 25You're right though, it isn't perfect.
I use a password generator that defaults to 256 characters, and literally nobody has allowed that yet that i've tried.
It's funny the arbitrary numbers some cut off at.
Many limit it at 32, a strange number at 40 for some reason, a few at 60, and others still will silently truncate it to some number on the signup form, then forget to truncate the login form...
There is secure, and there is silly. NIST recommends 80 bits for passwords. Anything over 128 bits is excessive, anything over 256 bits is silly.
A site I signed up for today limited it at 42. Why?
And even if 128 is way over excessive, does it actually make a difference to the server? Obviously you don't want to be hashing multi megabyte passwords, but don't most password hashing systems need a certain sized key to work, so it's padded out to that point anyway? And once it's processing further "iterations", the size of the first password is pretty much irrelevant.
Raise the point that forcing insecure practices on government operated financial sites might be a case of illegal negligence.
Also, can keepass generate secure passwords for you? That's something I love about lastpass.
UPDATE: also, how easy is it to use on an Android?
From what I understand, the encryption is done client-side per individual item (e.g. if you use a cloud provider, unencrypted data never touches them), but there's some generally questionable stuff in how it handles secure things: https://news.ycombinator.com/item?id=9727297
That is a non-starter....
You sync your DB across multiple cloud services, and to decrypt you use a weak master pass and strong key.
I've been struggling with how to move that key around.
.1) Put it on a USB drive or hide it in your filesystem.
This is cumbersome and losing the drive could be disastrous. It's also trivial to scan a filesystem for key-like files.
.2) Use an authentication dongle.
This one is better but requires third party hardware in most cases, and is slightly expensive.
.3) Bluetooth/NFC to your device.
This can be intercepted at extended ranges as proven at defcon etc. Though is admittedly the most convenient method. The data can be signed, but I haven't seen anything out there that implements this well just yet.
.4) Timed one time passwords, PushBullet etc.
This feels like a bonus feature.
I'm not sure how to go about this. You lose or leak the key then you're screwed.
Is there a wristwatch or phone app with signed credential sharing based on wearer input, compatible to a standard?
If you use diceware for everything you've got to remember all of those unique passphrases which defeats the whole point of diceware.
Where diceware shines is in creating a master password, which is explained in the guide.
Passphrases are not passwords and I think they shouldn't be recommended for use as passwords.
Passphrases are fantastic for encryption keys, where trying to otherwise memorise a suitable amount of entropy to match the required strength would be almost impossible.
But passwords don't need to be 256 bit. If you're using a password manager it doesn't hurt to keep passwords as strong as each service will allow, but Diceware isn't the right tool for the job for passwords, because while it's great for memorizing one or two high entropy phrases, there's no way someone could be expected to memorize the dozens of passwords they use on a daily basis.
At which point you're back to bad solutions such as writing it down, using the same phrase everywhere or cheating on the lengths.
The only sane way to manage dozens of services in a way that doesn't bleed risk from one service compromise to the next is password managers.
At which point a 16-20 character password of random characters is more suitable than a passphase. It's harder to memorize if anyone happens to see it due to a miss-paste or whatever, it's easier to type in if you need to and it's less likely to suffer from "silent truncation" effects.
So use a password manager, use a diceware phrase to secure the master password (encryption) there, but allow the password managers to generate passwords which are short and random.
Plugging my super simple passphrase generator built upon the EFF wordlist: https://spg.brashear.me