[orofino]

The question for us, as technologists, is what are we doing about this?

2FA is nice, but not the end all, be all. OAuth has largely failed to gain any reasonable traction. Using Facebook login means Facebook gets to track me as I move around the web.

Our users reuse passwords, primarily due to the proliferation of dozens or often hundreds of online accounts that a single individual has. We can't expect people to use password managers (they're complicated and then centralize everything into a single point of failure). Forcing people to use crazy passwords just results in weaker passwords.

I was hopeful that something like persona from Mozilla would catch on, but that has failed. Where are we with replacing the password? It is flawed technology.

On top of this we have the compounding factor that our systems are more complicated than ever and it appears that they're simply impossible to secure. Too many layers exist with too much code. Many sites just don't both with even hashing password, meaning those of us that care, are just kind of throwing our hands up and saying "well it wasn't my site that was compromised, so it isn't my fault". All the while, bad guys walk in the front door because we've decided to ignore the reality of the situation.

I know I'm not providing a constructive alternative here, but I'm a bit ashamed that we've even let it get this far. We're failing those that rely on our systems. I don't have the answer, but would love to hear some ideas about what can be done.

[drewcrawford]

> Where are we with replacing the password?

The state of the art of the technology, in my opinion, is GRC's SQRL: https://www.grc.com/sqrl/sqrl.htm

However I think you have captured something essential in the idea that Mozilla Persona "failed to catch on", and it wasn't, as far as I can tell, for technical reasons.

The real problem is that any change from the username/password system has a cost (in programmer hours, and support retraining, etc.) and so long as "nothing is broken" it is hard to justify diverting funds from features that are customer-visible to providing a defense against an attack that is arguably the user's fault anyway (password re-use).

To me this issue is sort of a monument to the strange insincere lipservice we pay to technology and technologists. Of course technology is business-critical and of course we work to hire the best and brightest, etc. But somehow organizations keep storing passwords in plain text in spite of the fact that engineers who work there know better.

[dingdingdang]

> The state of the art of the technology, in my opinion, is GRC's SQRL: https://www.grc.com/sqrl/sqrl.htm

This idea SERIOUSLY needs more attention, Steve is basically presenting a complete blueprint for how to do web login security right on everything from smartphones to desktops. A startup could run this implementation-wise and if the hype was right it could be a massive hit.

[orofino]

It is our job to explain to the business what the value is. It is our job to convince them of the value.

I know this can be hard/impossible in some situations. I've lost those battles for things that are much more trivial than replacing large parts of the authentication system. However, if you keep beating that drum and take any opportunity to push that goal, you can sometimes create the time to work on something like this.

Are your customers requesting some kind of compliance (SSAE or something of the like)? Use that as leverage. See the recent news (or not so recent higher profile Sony hack news)? We should really address some of our shortcomings.

The problem then becomes, what is the market pushing towards so that you can help push that forward. Right now there isn't a clear answer, solutions keep dying on the vine.

[napoleond]

Thanks for the link to SQRL, I hadn't seen that before. Very cool.

[droopyEyelids]

I advocate for the use of password managers.

I've bought 1Password for everyone in my family, and nagged them into using it. I console people online to do the same, or use keepassx, or last pass.

It's not effortless security, that's for sure. In a perfect world we would have a better system than passwords. But we live in a world of compromises, and I feel it's presently the wisest course of action.

https://lastpass.com https://agilebytes.com

keepass or keepassx should be googled.

[jacquesm]

It would be a great start if sites that don't actually require an account to get the job done would stop asking you to create one. For instance, most e-commerce transactions where you buy a single item still require you to register with the store. That's like having a loyalty card forced upon you because you tank gas somewhere.

Usually I just want to buy the item, not become 'a member'.

[porker]

> I was hopeful that something like persona from Mozilla would catch on, but that has failed.

I talked with two people from Mozilla at a conference in February and was disappointed (though not altogether surprised) to discover they couldn't articulate the compelling reason why someone would move to using Persona. For something to mainstream, the marketing, positioning and ease-of-use is crucial. They had no answers other than 'privacy' and 'ease of use' -- which while valid, aren't going to convince my aunt & uncle to adopt something new. Until they've been hacked, scammed and otherwise suffered pain.

[csacc]

Just throwing this out there but when signing up for sites while using Safari, Apple gives me the option of using a (Apple generated) random password that is stored to my keychain and synced to my iCloud account. This means both of my MacBooks, my iPhone, and my iPad all have access to these sites with no effort on my part (I never could remember my passwords) while also being random and secure(-ish?).

All that is needed is a service (Microsoft, Google, Apple, Facebook) that you trust as your password manager and is integrated either with the sites you browse or the browser you use.

Having read Apple's iOS security document (http://www.apple.com/ipad/business/docs/iOS_Security_Feb14.p...) I have just the right combination of convenience, ease of use, and feeling secure with their services to use keychain for most of my password needs.

[rst]

Awkward time to bring up iCloud as a potential SPOF for users' security. Apart from technical flaws in the service (and any cloud service is likely to have one eventually), cryptographer Matt Green (on his twitter feed) has pointed out that Apple chose some poor defaults, particularly the use of peoples' phone password as default for cloud storage. Quoth Matt, "Of course people pick terrible iCloud passwords. You can't enter a good password 50x per week on a mobile device. You'll go carpal." (In subsequent tweets, he acknowledges that password caching would help with this, but says he had to turn it off after his kids ran up a $200 bill.)

Of course, it's not clear that password brute-forcing was what led to the recent leaks of celebrity nude selfies, and not even complely clear that they came from iCloud (though a lot of clues point that way). But regardless, they do illustrate the risks of relying on cloud storage generally, regardless of who provides it.

[SomeCallMeTim]

Sorry, but there's no way I'd allow any cloud service to hold my password vault, and recommending it to end users seems like a colossally bad idea.

I'd want at least two layers of different encryption types (generated by distinct software) protecting any such file if it were to be stored in the cloud. That way if one software package or one encryption algorithm were compromised, there would at least be a chance the other layer would protect it.

So at the moment I put my vault on my laptop and copy it directly to my phone, but I don't copy it into the cloud, ever.

I might consider using something like SpiderOak [1] in conjunction with a Keepass encrypted container, for instance. But I haven't even done that.

[1] https://spideroak.com/

[logn]

> Where are we with replacing the password?

What about you load a site, get an HTTP 401 response, your browser sends back an auth header with a password generated for that domain name, based on some secret global key/password. Then in response, most sites would set a cookie. To change the password, you could have a second header that has the new password, along with the original. No usernames needed. The browsers would have a global password for cases of shared computers. Log out buttons on sites just remove the cookie. Or without cookies, just have the browser send the auth header each time until a native log out button is pressed.

[Perseids]

>> We can't expect people to use password managers (they're complicated and then centralize everything into a single point of failure).

> What about you load a site, get an HTTP 401 response, your browser sends back an auth header with a password generated for that domain name, based on some secret global key/password.

You essentially describe a password manager with deterministic password generation. It has all the upsides and downsides of a regular one, except migrating passwords is harder (you need to change them instead of storing them).

[bambax]

All the security measures usually presented (including here) are completely unrealistic - no one can use different, complex passwords on every site we log into, and then change them every month!

The only way to do this would be to use a password manager in an Saas mode... and if it gets cracked then you're completely doomed and lose all access to all services.

People probably assume that the time saved by not caring about security is greater than the time they will lose if (when) they're attacked, and they may be right.

[tribaal]

I do exactly that, using keepassX. Single use, complex passwords that I change every two months, stored in a shared encrypted database.

What exactly is hard about it?

[bambax]

keepassX seems to be a local application: how do you use it on mobile, or when you're not at home?

Also: if the database gets corrupted, you lose access to all services; if you have backups then it's a little less safe; if the main password for the database is strong you may forget it (or need to write it down somewhere outside the system); if it's not strong it's not safe.

[diafygi]

There are mobile clients for KeePass databases. So you just need to keep a copy of your database on your phone. That's extremely easy to do with syncing data apps like SpiderOak.

[quoiquoi]

Soooo you're still using a cloud service to sync your passwords, right?

[mynegation]

I cannot say for Android, but if you keep kdbx file on a Dropbox, you can access it with iKeepass iOS app

[jimlei]

Android clients exist for both keepass v1 and keepass v2 :)

[eik3_de]

why shouldnt the average user write down his/her master database password and store it in the kitchen drawer?

[dredmorbius]

Does keepassX manage the password changing or is that something you schedule and do manually?

[quoiquoi]

You still have to do it manually I think. Having a standardized API to change passwords (a "Rotate all my passwords" buttons) would be nice, but potentially a huge step forward in automating password attacks.

[dredmorbius]

Thanks. I confirmed a Debian package. If I can sync devices I think I'm golden.

[nevir]

We need to move past passwords.

[prawn]

Whatever the solution is, it needs to allow remote permits. e.g., I need to be able to grant an employee access to my NameCheap account for client work purposes.

[CamperBob2]

True, and whoever pulls it off is the next Mark Shuttleworth, if not the next Bill Gates.

[tomelders]

I don't think there's anything wrong with user-names and passwords in concept. It's familiar to users and easy to implement. Users need to create better passwords and we need to help them do it.

Don't impose any restrictions on what the password should be, e.g. "Must not contain any special chars. Must contain a number..."

Use the word "pass phrase" instead of "password". Encourage people to use memorable phrases and quotes as their pass phrase. The English language has approx. 250,000 words. If a pass phrase contains 4 words, that's 1.62764322e+20 permutations. That's a naive view since "habit osteopath circumference telephone" isn't a particularly memorable password. With this in mind, You could use statistics to reduce the number of permutations, but that's no small feat.

Use email addresses instead of user-names.

Finally, use Bcrypt.