Hacker News Reader

> a better way to solve this is at the browser/OS level with built-in password generation and management

I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon.

KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time.

About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists.

[1] https://news.ycombinator.com/item?id=5743057

I feel like we're missing the elephant in the room.

The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.

This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.

But the real authentication happens when you enter your password to access your email.

Therefore, when I read:

> I think a better way to solve this is at the browser/OS level with built-in password generation and management.

All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?

We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.

Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).

Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).

From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.

So, is it really a better way to solve this? Not currently.

A few thoughts about the current de facto authentication 'standard':

1. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part.

2. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better.

3. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less.

4. But, sometimes I want to authenticate anonymously.

5. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information.

6. And, if I lose or break my phone, I don't want to lose my identity - I want an easy way to encrypt and store my identity at multiple backup locations.

> All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?

It's not just about trust. There are also a significant technical drawbacks to piggybacking email for authentication, namely the two I mentioned (security/convenience and reliability).

You should take a look at iCloud Keychain. It does a better job at tackling some of the drawbacks you note with Firefox Sync, especially when combined with Touch ID as a more convenient master password.

About the 2FA thing, Authy is a Google Authenticator alternative program that allows you to keep several devices, including computers, with the ability to generate those codes. Might be what you need to both use 2FA and not worry about having the phone always with you.

Although, sites that uses 2FA usually don't ask for the phone code very often. They use it more to authenticate the device you're using. If it's your home computer, you only use the code once every month or so.

2FA feels like a chore before you actually uses it. I know because I resisted it for a few years. Now I complain when a service doesn't have it. :P

> Authentication is or should be a much more common event than recovering a lost password

For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.

I think a lot of people do this for infrequently visited sites, but:

1. It generates at least 3 new database transactions each time it happens, not to mention the associated crypto requirements and email.

2. This password recovery system is a common attack vector and vulnerable to social engineering attacks and MITM attacks.

3. It is mostly obviated by the existence of password managers. For those with the knowhow to do this sort of thing, all of this sort of stuff should be happening on the client side.

3) is not really useful if you login quite often from different devices that aren’t synced, so you can’t use a password manager.

well if your password manager is cloud based or each device knows of the others existence you could pull it off. I would not mind the later.

For your #1: For sites with low security demands that will be Ok. GMail already does it. When I enter GMail it always gets me logged in by an cookie and that lasts for a month or so, only after that period, I have to enter my pw again. Of course, when you do some security relevant changes (like changing passwors ;) ... just kidding ... changing eMail adress), a reauthentication is needed.

I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much.

BTW: I also described a similar idea some time ago in a blog post: http://strategieneu.blogspot.de/2014/06/email-only-registrat...

After I wrote it, that such ideas where discussed at HN even some time ago.

While Gmail sessions are fairly long-lived, I wouldn't say that this is an example of a site with low security demands. Email is pretty sensitive.

Yes it is. But still Gmail sessions are long-lived. I also would not stretch this system to eMail-access. Blame it on Gmail, that they do not enforce more security.

It works because they aggressively monitor for session stealing attempts and immediately shut them down. So it's long lived but with an impressive amount of monitoring that really isn't within reach for non-Google companies.

I can tell you: They do not.

I made a small program to access Google Keep automatically. Because I was too lazy to implement proper authentication, I just hardcoded my session keys. The app is started from a different IP, using a different user agent and is STILL able to access the site after weeks!

(Nowadays I have proper authentication in there, but it’s still worrying that stealing sessions from Google is so easy. Especially because some Google services submit their sessions keys via HTTP, without SSL)

That is not enough evidence to conclude that Google does not monitor for session stealing. Lots of people have dynamic IPs and user agent strings are easily spoofed. They're going to be looking at other factors, like where the IP is located.

I can tell you they do. Within seconds of clicking on a compromised URL they had locked down my account requiring a text to unlock it. I was deeply impressed.

I don't think, that such a scheme can work, when somebody else is using my laptop. Sometimes the simplest attacks are the most effective.

The long log-in duration doesn't really bother me in and of itself. No-one uses my computer without my permission, and no-one uses my browser, period (I create new accounts for people).

If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.

That might work for you, but not everyone. General website authentication systems need to work for the masses. And the whole point is shortening the session makes this system very inconvenient to use.