I'm a little tired of writing about passwords. But like taxes, email and pinkeye, they're not going away any time soon. Here's what I know to be true, and backed up by plenty of empirical data:
For those of us that do have to store user credentials, what would you recommend as a plan of attack? Iâm confident using salt and the basics for password protection, but Iâm never sure if thereâs more that I could do, or where to look for modern, relevant info on the subject.
Yes, it affects me but I really have no sympathy for all the griping about passwords and whatnot from the tech community.
Remember when Microsoft tried the âInternet Driver Licenseâ with Passport? Everyone flew off the handle hysterically proclaiming Microsoft wantâs to control the Internet, theyâre going to login to all you sites and steal all your information, you canât trust a central password server, itâs better to have different passwords in case one get stolen, and on and on an on.
That killed the whole idea and even when Liberty Alliance (I think thatâs what it was called) came along as the âgood guysâ, the damage has been done.
This problem cold have been reasonably solved 10 years ago if it werenât for the totally irrational paranoia over Microsoft running Passport.
There is a secure password generating scheme that can be carried out in your head. Essentially you create a cryptographic hash of the site name using Manuel Blumâs algorithm. More details here. It takes a lot of effort to learn, so not many people will use it, but itâs interesting that itâs even possible.
What about SQRL and FIDO? I mean, I guess those are still a long ways away from getting widespread adoption, but they seem like they could make for some pretty solid password replacements once they get over that initial hump.
The Password Hashing Competition is currently ongoing and searches for an scrypt replacement.
Scrypt is quite complex, vulnerable to Cache Timing Attacks and lacks some nifty features like client-independent updates(increasing the complexity of the hash calculation without requiring the user to login).
Depending on the situation you may want to encrypt your hash or use a keyed hash function. This is useful when e.g. only your database is leaked. Without the key the hashes are just a pile of garbage for the attacker.
Important topic, but I think it kinda misses the main point.
It doesnât really clear who your targeting and what is the threat model,
the regular users ? which as you mentioned will probably wont read this article and wont change any of there day to day behaviour any way. on top of that if they are using the same password on more than one site itâs length is irrelevant. there are so many crappy sites out there that in the end they will bound to fall on one that doesnât encrypt there password, and that will be the one who is also full of sql injections and will have it DB leaked. If they are using unique passwords for each site, they donât really care about offline brute force since that means that the site has been already compromised, the only use for the cleartest is if it has been used somewhere else.
web developers ? great use Scrypt as the hashing algorithm, but then its ok for your users are probably ok with a 8 character password, your brute force speed calculation seems to be assuming a really fast hashing. But from your article it seems like Scrypt is not strong enough to protect 8 char password so why would A developer choose to change is old and trusted md5 for it ?
the super paranoid Hacktivist ? he already knows that any site he uses is accessible for government agencies even without cracking the hash, and they can probably get the plain text before its being hashed if they really wanted to. the only password he might want to protect from government agencies are the ones that he uses to locally encrypt his data.
Since you link grc.comâs password crack checker, you probably already know about sqrl, Gibsonâs awesome password-less* authentication scheme, but just in case: https://www.grc.com/sqrl/sqrl.htm
*â> well, no password are stored server-side; you do use a password for your local sqrl client, but only one so you can more easily convince users to select a strong password.
Link to GRC without mentioning SQRL?
To be a cybercurmudgeon:
Your ego is too damn big.
Is anyone really going to care about hacking commenting accounts here or elsewhere?
Somehow Iâm logged in and commenting, but this is not an encrypted nor authenticated connection. Have you not heard of âFiresheepâ?
For my critical accounts, I do have really long, complex passwords.
For the accounts where I post my whimsical musings on everything and donât give a damn if they were hacked which I donât think they ever will be bothered about, I use one simple password. Or the same slightly hard or some variant if they insist on having bank level security (Note - one credit card portal insists on complex passwords, and remembers previous ones but uses a really weak SSL cipher - sigh).
Then thereâs the simple problem of security. A basic HTML form isnât likely to have any leakage problems, nor ways of hijacking it. Complex javascript? Did you review it? Does it meet security standards? Have you had your entire site (and any offsite things you use) pen tested?
Some people insist on putting a bank vault door in the drywall-stud space for their lavatory. And insisting on TSA style security theater.
It is easy to pick on passwords as being simple. It is much harder to insure your site is secure so that they canât get the hashes (and I hope you are salting them and not using an obsolete or insecure hash algorithm).
The problem with using Google/Yahoo/facebook etc is that its never just authentication. For example I signed into Discourse to leave this comment with google which told me that Coding Horror would get access to âView your email address, View your basic profile infoâ - why on earth should I share all of that to make a comment.
And thats a nice site⊠most of the time with facebook logins you are asked to share your friends list and posts and all sorts of things. Until sites reduce their requirements to the minimum its not something I like to use e.g. Iâm happy for Discourse to know a public email and a public forum handleâŠ
Any chance of authenticating on websites using my SSH public key?
Iâm weary of storing high-value passwords in the browser, since itâs easy for malware to recover them if your desktop ever gets compromised. Using hash(domainname, my-global-password) seems like a really smart idea. Nothing to store in-browser, and you can securely use the same password everywhere. Throw a 100 byte salt value in as well and youâre good till the end of the universe.
All thatâs missing is a decent in-browser UI.
Using a decent password only makes sense to me for any site which I would actually be sad if someone hijacked my account. Thatâs only about 5 percent of the websites I go to. For a site like Stack Overflow, the value of being able to remember and easily type my password without making mistakes is much higher to me than the value of preventing someone from sabotaging my account.
I agree with what andyDunn said about the downsides of using Google / Facebook for authentication. Though in some circumstances like posting on this forum I went ahead with it because the time wasted by creating an account from scratch would outweigh the benefit of voicing my opinion.
Overall, in most situations, it seems to me that creating an account with a weak password is the best option.
Amen! Now letâs convince online banking industry to support strong, long passwords. I have a few banking accounts and most of them donât even allow special characters.
Pretty much what I said in the article: try to use scrypt if you can, if you canât, then follow the Matsano recommendations, in the order stated:
N=2^14, r=8, p=1cost=11iterations=86,000We used #3 in Discourse with 64,000 iterations⊠the tricky part is you need to increase iterations as time goes on and hardware gets more capable, but that invalidates previous password hashes, too, so you need to version them somehow.
Old versions of software have comically bad hashes. Look at NTLM versus MD5, itâs nearly twice as fast to beat. And those old software user databases are sitting out there, forever, waiting for someone to find the hashesâŠ
Well, some ideas are simply (and sadly) ahead of their time and fail.
Wow this is so hardcore! 
To use Blumâs method you must memorize two things: a random mapping of letters to digits, and a random permutation of the digits 0 through 9. The random map and the random permutation are your personal keys so you must keep them secret. They must be truly random â any pattern that makes them easier to memorize may make your system easier to break â and thatâs why this up-front memorization is hard. But it only has to be done once.
Itâs fair to note that Scrypt is pretty new, having been invented in 2009, but it was a reaction to very fast custom hardware that is now ⊠almost everywhere.
Any of the 3 I listed at the top of this post (and Matsano recommended) would work fine. The numbers in the GRC checker are for really simple worst case scenario stuff like MD5. You can multiply those by⊠a lot. I mean compare these numbers from actual GPU crack tries ⊠note that these are in millions of attempts per second!
Be careful because this also depends on the # of iterations chosen, though! Thatâs why they recommend a large number of iterations because thatâs also a divisor here, you are not calculating this hash once, but (n) times.
You have to plan for worst case, because you have no idea what hashes are being used behind the scenes, and how old the software is.
I do think itâs a good idea for users to know that really and truly they need to be picking passwords of at least 12 chars in length if they donât want their stuff trivially compromised when the user database leaks â particularly since users re-use passwords all the time! So all it takes is one leak with a 9 or 10 char password and that email/password combo is now burned on every service. Triply so if like most users they only used uppercase/lowercase or lowercase/number!
Thatâs why Discourse is open source⊠anyway, this is about reasonable defense, and I no longer believe that an 8 character password is remotely a reasonable defense even for an average user. With the hardware thatâs out there, 8 character password hashes, even using the full complement of ASCII available, are a joke to crack. Trivial.
I am a big, big fan of using the domain name as part of your personal âformulaâ for the password you use (like a kind of salt, basically). It makes a lot of sense and I recommend it.
All fine, but make sure that simple password is at least 12 characters. And has uppercase, lowercase, and numbers.
At the same time, there are still services out there that have arbitrary restrictions on your password in place, making you have do with a less secure password than you intended to. Plus, it gives attackers additional information they can use to tune their algorithms efficiency.
Worst offenders I came across:
Of these examples, I am mostly shocked by the Microsoft case. Youâd think they of all companies would be concerned with security.
12 Characters in the minimum assuming you donât use the same password on a site/system that stores it in plain text (people still do this in 2015 sadly), getâs hacked and your password ends up in a password database. .
You also need multiple passwords for all your accounts and never share critical software passwords with non critical software.
I use the following pattern:
Critical: Home banking accounts must use unique password not shared and very long (mine 20+ chars)
High: Google like identity providers (15+ chars) not shared
Medium: Social networks, 12+ but generated based on the same pattern with a derivation rule
Low: Occasional accounts, 8 char throw away password, shared between all accounts.(I know this is bad, but Iâm not a machine, I canât memorize dozens of passwords. I also rather not use password managers, they appear to be the week link in case of an attack)
The last time I signed up for something with Google, it asked me if it could share X, Y, and Z with the connecting site, with the option to say ânoâ for specific items. So, for example, yes the site can see my email address, but no you cannot see my contact list. Is that feature optional, and some universal login connections are all-or-nothing? (Iâd certainly expect all-or-nothing out of Facebook; if thereâs an evil option, you can trust Facebook to choose it :-/)
An earlier post referenced SQRL, which uses your private key (not sure if it can be the same as your SSH one, but itâs yours) to generate signed authentication. You can also use PKI to perform client authentication with a keypair, keeping in mind that generally you have your keys issued by a trusted authority.
Of course both would need buy-in from the site in question, and critical mass is the biggest hurdle to overcome. Whatâs more likely to get wide buy-in, âdownload and install this toolâ (SQRL or a keypair generator), or âuse the {Google/FB/Yahoo} account you already haveâ?
Speaking of PayPal - I find the âmaximum password lengthâ rule, endorsed by companies like PayPal (20) or Microsoft (16, what the hell?) really really annoying and, whatâs important, counterproductive.
And whatâs more, these companies seem to disregard any and all complaints from their users (I was personally engaged in a year long email exchange with PayPal, leading only to my frustration and dismay. I havenât even tried to contact Microsoft about it, for the sake of mental sanity).