This is a nice article. Only thing missing is calling out "secret questions" as asinine.<p>I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries.<p>Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (<i>cough</i> United Airlines <i>cough</i>).<p>And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (<i>cough</i> again United Airlines <i>cough</i>).
Ah, passwords.<p>Look, webmasters, the simple truth is - I don't care. I have a default password that is very simple to memorise (and hence guess/hack), that I use for most logins, because frankly, I just don't care. Unless you're vitally important to my life (email, Facebook, backup, services that I use so often that they keep my personal/credit card data), your login/password is just an annoyance for me, as is your password security policy.<p>I commend reddit and webshops that allow "checkout as guest", that recognise this.
This is a great article, but it doesn't acknowledge that there is sometimes a tradeoff between security and profit.<p>For example, imagine a typical user who tries to choose a password:<p>User: I want my password to be "monkey"<p>System: Sorry, that password is in the dictionary<p>User: OK, I want my password to be "monkey1"<p>System: Sorry, that password is on a list of exposed passwords<p>User: Grrr! OK, I want my password to be "monkeymonkey"<p>System: Sorry, that password is on a list of exposed passwords<p>User: Grrr! OK, I want my password to be "monkeyfuckyou!!!"<p>System: Sorry, that password is on a list of exposed passwords<p>User: Screw this, I'll just sign up with one of your competitors.
For anyone who is thinking about using unicode for passwords, remember to normalize the unicode before hashing it. Different human input devices may output different codepoints for what appears to a human to be the same character/string. Obviously make sure you manage the decoding/encoding as well.
Here is what NIST has to say about allowing the user to display the password on screen:<p>> In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.
Math tells us longer passwords are better than longer alphabets, yet I am often forced to add special characters. If I have 12 character password over an alphabet of 26 characters, there are 26^12 possible passwords. If I have the choice between adding 5 special characters or increasing the length of my password by 5 characters, math says do the latter:<p><pre><code> (26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24
</code></pre>
That's over <i>six</i> orders of magnitude higher. How come supposedly computer savvy people don't know the difference between x^N and N^x?
On systems that disable the pasting of passwords: could I give a special shout-out to Apple OSX which, in 2017, still refuses to allow users to paste a passphrase when the ssh agent pops up a window to request it?
One thing which I find Troy constantly misses to advertise and which I personally think is a much better solution than using password managers and each individual system having to develop their own login + verification and security system is to use 3rd parties to authenticate.<p>I am a big fan of password managers, but I don't think there is a need for them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email.<p>If someone gets access to your email address then they have effectively access to every single service you signed up with that email. Therefore every single service might as well just use Google/Hotmail/Microsoft/etc. to authenticate their users instead of building their own login system and asking people to come up with a new password which forces them effectively to use a password manager and yet another place to store all eggs in one basket.<p>The password to your email account == the password to your password manager.<p>If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we would be even more secure then everyone having to use a password manager, and it would be a much better user experience. Also I am pretty sure that Google + Microsoft + Facebook have a lot more talent + resources to secure their accounts then every new service which pops up every day. Let them do the security and you focus on your actual business value...
When I talk about security, the question I like to pose is this:<p>Imagine every password for every one of your users is published...can you identify people? How would you clean up the mess? Imagine a malicious person logged into EVERY one of your user accounts and tampered with them, changed email addresses, etc. Can you identify it? Can you clean it up? Can you prevent it from happening again?<p>If the answer to any of those is no...then you're sitting on a time bomb.<p>Start with the assumption that the username and password is convenient but unreliable, then move forward with actual security.
The problem with a password manager is that you don't have easy access to one when you're on a different machine.<p>A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password.<p>This is why these arbitrary demands need to die: they make the only way to securely and conveniently access accounts from different devices impossible.
Does anyone provide a regularly updated bloom filter of exposed passwords you could use for meeting the last point? Seems like something Troy could do...
While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being. Even if UI and market standards for cryptographic based auth finally gets improved, it'll still be a long haul for it to grow in usage. That being said this seems like a solid overall listing of the basics that all password using services should follow, except as koolba said earlier "Security" Questions (scare-quotes extremely intentional) were always a horrible anti-user & anti-security idea and should be eliminated everywhere.<p>My only actual quibble/concern with this piece is in the <i>"Notify Users of Abnormal Behaviour"</i> section. I agree it's a good idea in principle to perform notifications, the only niggle though is that some common forms of notification are not authenticated in general, and in practice that particularly means email. I have only ever seen a few companies, even in the financial sector, that sign emails (and without that more aggressive automated domain anti-forging is hard too). At least from the stats I've seen on my own servers and for users I'm responsible for, "Notification/Alert" emails are an ever greater favorite of spearphishers & spammers. A lot of the major companies deal with this by using better authenticated purpose-made notification systems or even just text messages, but email still enters in, and if the practice spreads I'd expect to see a lot more places just using email. I think it's worth being careful about getting users trained into any habit that might lead them to immediately assume something from an unauthenticated source is real and should be clicked. This might be an area that'd be worth coming up with better standards and UI for as well.
The problem with passwords on the web is that they require sending and trusting private credentials to someone else. As devs we need to working on making better systems (e.g. TLS client certs and SRP (e.g. TLS-SRP or PAKE)) more usable.<p>It's not a magic bullet and not something a switch can be flipped on, but the status quo is terrible.
One thing that bothers me about this article, and the way everyone does passwords is this assumption that the output of a cryptographic had function is alphanumeric. It's not, is binary. Store the actual data in your database, not the base16 representation! This applies to anything, not just passport hashes—don't transmit around data as base64 unless you're actually using a medium that requires it (e.g. email)
passwords are clearly still a gigantic problem in infosec for the users <a href="https://blog.binaryedge.io/2017/07/24/antipublic-password-analysis/" rel="nofollow">https://blog.binaryedge.io/2017/07/24/antipublic-password-an...</a>
Whenever a site requires special characters, it just ends up limiting me to one of the few memorized passwords I have that matches the criteria, most of which are barely 8 characters long.<p>I use LastPass but I don't like using the password generator because I want to be able to log in on mobile or other computers when necessary, but I don't do so enough to justify signing up for a subscription (I dislike subscription models) that would allow me to access use it on mobile.<p>I wish I could just use giant password strings on all of my sites.
Excellent read. I've finally decided to do what I've been saying I would do for two years and create an open source demo Ruby on Rails application that applies these principles using the Devise gem and a few others. Will show it supporting multiple two factor strategies as well as account lockout, recovery, and access downgrading based on confidence. It's a private repo at the moment but I will share as soon as its worth showing.
I like the concept of "Notify Users of Abnormal Behaviour" but how. I mean that in a technical sense. This XKCD seems to apply[0].<p>People take for granted that an organisation can just hook into a bunch of paid external services, GeoIP, Browser/Device Database, etc. First off, there's a great many organisations who cannot or will not be able to use an external GeoIP database for example, and even if they could how is a threshold of "abnormal" determined?<p>I too love Facebook's implementation. How do I make that without hooking into half a dozen paid external providers? I'm legitimately asking, because this seems like a "research team and five years" type of issue.<p>[0] <a href="https://xkcd.com/1425/" rel="nofollow">https://xkcd.com/1425/</a>
Is there an independent body that certifies that a site uses good practices? I mean, I have no way of knowing whether a website is storing my password in the clear (unless they email my password to me), using a symmetric cypher, a site-wide salt, etc. It would be nice if a trustworthy party could investigate a site's security practices and certify that they are doing things properly.
Or you can move beyond passwords.<p><a href="https://github.com/Qbix/auth" rel="nofollow">https://github.com/Qbix/auth</a>
A person only has so many memorizable passwords that they can hold at a time; the entropy source is very very low rate. Revealing <i>any</i> memorizable password to stupid random sites is itself an antipattern.
What is the consensus on not allowing previously used passwords?<p>i.e., when changing your password: "You used this password too recently, you can not use your last 20 passwords"
No mention of how to authenticate on mobile? I don't think a guidance on how to authenticate for the Modern Era is complete without having a mobile solution
I'm curious; why aren't we dropping the use of passwords in favor of U2F?<p>I guess for one; not everyone wants to buy and carry a key. But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
I believe eventually passwords will become cognitive thumbprints. I.e. instead of a password, we play a short game, type in some text of which the cadence can be analysed.
>Embrace Password Managers<p>I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't look like he completely understands the whole problem. The main problem is that passmanager holds a lot of metadata.<p>For example, you use unique password with high entropy for every service you use. Once attacker gets your one master password (through zero-day or just by watching you type it), potential damage is massive. He doesn't have to try to find where you are registered, password manager will tell everything, about every single account and possibly more; some people even store credit card/banking info in passmanager. At that point it's over, you lost.<p>"... if (password manager) gets compromised it's going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials."<p>This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes. With good hash algorithm, he have to spend considerable amount of time cracking every single hash. He doesn't target you in particular. You are just one of many. If attacker cares about you, after cracking hash and getting your password, he has to do a lot of research (trying to find other sites where you used that password and hope you didn't change anything there) to make any use of it. Objectively, he doesn't actually have much. So going after popular services you use, just to get your password, doesn't look like a good attack vector in the first place.<p>People should know, that password manager is just a glorified notepad file with one password. By using them you are trading safety in situations when attacker targets you, for safety in situations when attacker targets someone else and you are just a collateral damage. If you must, use them only for information you don't care to lose.