Password Security: Why the horse battery staple is not correct

You have to be pragmatic with users and offer them a path of least resistance while implementing a greater level of security. I've only recently been able to get users to pay attention to why they need a password manager - the iCloud hack helped more in that than even Snowden did.

That path of least resistance right now, I find, is installing a password manager and securing it with a primary password that is generated from four or five dictionary words. Combine that with two-factor authentication for the most important accounts (Google Authenticator is surprisingly easy to teach people to use).

You find corner cases that cause problems: apps that don't support automatically having the password entered, or pasting the password in, mobile apps that become frustrating to enter long random passwords into so users just change them to something simple (including Apple ID's).

Four random words is beyond 'good enough' and far better than what most users are doing now. Rolling out and advocating new security measures is much about compromise and pragmatism. When somebody who is an ordinary computer users asks you what a good password technique is, do you spend 60 minutes explaining entropy and how people are bad at generating passwords (putting them to sleep), or do you just point them to a comic and one of the random xkcd password generators?

The iCloud hacks have done more for security awareness than what a million blog posts could ever have. It would be good to take advantage of it with a common approach rather than mixed signaling (I just know that at some point i'm going to hear someone say "but I saw something on hacker news about how those xkcd passwords aren't secure" - and I will have to take a deep breath).

Advocacy now could be focused on developers, where there is some catching up to do - a common protocol for password managers, allowing copy and paste, hooks in apps, agreeing on a set of weak passwords that should be not allowed (a lot of services already do this, most use top x from RockYou), removing those silly character restrictions (example: apple ID's can't be XKCD passwords since they enforce a capital letter and number), building password generating into more systems (based on an open spec - it should be an OS feature, not an app)

Password managers, combined with randomly-generated passwords, solve the most serious problems afflicting user-selected passwords. Adding two-factor authentication solves yet more problems. And yet both password managers and 2FA are not widely adopted by users. Where do we go from here?

I use a password manager, and the UX of registering to a new website is just awful. On the registration page I need to check what sort of password is being asked for (e.g. 'no longer than 15 characters'), and configure the password generator accordingly. After registration I need to manually convert the password into a login; my password manager can try to do it automatically, but it often fails because it doesn't know how to translate fields from the registration page to the login page. Compare this with what most users do: just enter the same password everywhere. Much less friction.

I think we can make using password managers easier than entering the same password everywhere. We can do this by introducing a standard web interface for password managers. This interface will let browsers fill in usernames and passwords on registration and login pages, automatically. It may include password specifications, such as 'password should be between 10-15 characters long'.

Here's the use case: imagine the password manager is integrated with the browser (say as an extension). When it detects this interface on a web page, the password manager hides the password field, replacing it with a message like 'secure password is auto-generated'. Similarly, login pages that support the interface will not show a password field at all. From time to time, the user has to enter their single password (to allow the password manager to access its database). In this scenario, the user has to do less work (on average) than when they enter their password manually. When no password manager is installed, the browser simply displays the same old password field.

Given a standard interface, implementation is simple: on the server side, it's just a few tags that specify user and password fields on registration and login pages, and what to replace them with when the password manager works. There should probably also be a site identifier to let the password manager know which registration page corresponds to which login page. (Currently password managers rely on URLs to figure this out, and this heuristic sometimes fails.) The whole architecture of storing passwords stays the same. On the client side, password managers already do much of this work anyway, including trying to heuristically figure out which fields correspond to the username and the password. This sort of interface makes things much simpler for them.

YES. Plus, this kind of integration would make it trivial to change a password, so that could literally be a one-click process in the case of a leak.

And as you say, password managers already have a fallback for sites that don't support the interface, so there would be backward compatibility as it gets adopted. (And likely it will take a long time before businesses like my bank, which requires a password of exactly 6 alphanumeric-only characters, catch on...)

I've found banks on average to be absolutely terrible with password security. I mentioned in another comment, my bank requires a password of exactly six characters, alphanumeric only. It's like they're trying to make it as crackable as possible. (I believe the reasoning is that they want you to be able to enter it for telephone banking using a touch tone phone, but obviously it would be far better to use a separate password for that. (Especially since I expect there's little overlap between people who use automated telephone banking and people who use internet banking...))

My point is that you are taking what should work behind the scenes (common shared secret) and forcing a user interaction (typing or copying out a code) because synchronizing that secret across user accounts on disparate devices is considered "too hard" a problem, even though like I said the browser can be a perfectly good commonality and Persona was on the brink of fantastic innovation on that front.