It's really a shame that we haven't solved this problem yet as an industry.
I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive.
When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed.
There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world.
There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method.
Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.
This has some advantages but there are negatives too. Do I really want Google or Facebook to get a notification every single time I log in to a service because they get an email with a "magic link"?
Google / Facebook already know enough about services used, do we really want to transfer even more information their way?
Also, another trouble with this is the loss of anonymity.
There are very few places to register an email address without an SMS number. There are few places to get an SMS without a real name and address.
Yes, I'm sure there are places to get these things for someone willing to put in a lot of effort, but for everyone else, their email provider has their SMS, their SMS provider has their name and address.
So by requiring email as authentication, essentially every online identity comes back to your real name and address through a small number of hops.
It used to be possible to spin up a TOR session and interact with real services you would otherwise use. Between the crunch on anonymous email and cloudflare's endless captchas, TOR is increasingly useless for interacting with normal services.
This is a feature, not a bug. Unfortunately it turns out that many people are abusive when anonymous and use that to their advantage so anonymity has been curbed to keep control over that problem.
> There are few places to get an SMS without a real name and address.
I'm building a service to solve this problem right now. It works already and I hope to make it live within the month, it just wants styling and polishing.
The idea is you sign up with just a username and password, no email address required. You pay with Bitcoin and can buy a mobile phone number, from a selection of countries, for ~$3/mo. You can then use the web interface to send and receive messages.
Email address in my profile - please get in touch if you're interested in learning more.
Mail.com? Outlook.com? A lot of them, if you provide an SMS number, you'll need to verify it, but you can skip it by providing security questions or an alternate email address (that itself does not need to be verified).
There are already Gmail/Microsoft/Facebook providing single sign on for users.
That doesn't mean applications are bothering to support them.
Actually, Facebook is ubiquitous for popular apps to the point it's often mandatory. (too bad for privacy :( )
Google App for business (and Microsoft to a less extent) have market shares among professionals but many SaaS and hosted applications cannot integrate with it at all.
Good points. I'm not proposing a single owner, but rather a federated protocol where sign-in operates over email with each person's mailbox provider. The hope is that each mailbox provider will provide the sign-in.
You seem obsessed with one implementation. Passwords themselves are obsolete.
Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
Yeah - but that's like saying "email security and integrity has been solved for two decades", while _technically_ true, how many of you have talked your mom through setting up PGP and had her then "just use it"? (or tried to handhold a less-than-technical colleague through getting a StartSSL account?)
I'm pretty sure if any service less-technical than a CA authority starts pushing wide-spread user-driven in-browser certificate-based authentication, within days there'll be scammers and phishers faking the setup process to install untrustworthy ssl root certs so they can mitm Paypal/Facebook/everybody... How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate, and installing, say, the Charles Proxy ssl MITM cert?
> How would _you_ explain to your mom the difference between installing Pinterest's new authentication certificate
Actually, even with current terrible UIs, there's a reasonably big difference between installing client certificate (there even used to be a <keygen> HTML tag for those - although it's unsurprisingly marked as "deprecated" now) and trusted CAs.
Browser vendors have refused to touch that for years, so everything PKI-related has a cryptic UI hidden beneath 3+ clicks deep in the most obscure settings dialog areas. And some pieces are completely missing, like session state management (it's just like with HTTP auth - there are hacks to implement it, but they're hacks).
Another issue is, with current implementations not really fancying the idea of CA-less self-signed client certificates, so you'll most probably need a certificate-per-site approach. And with a ton of certificates (even if they all for the same public key), you'll need to automatically sync them to another devices somehow.
(The usual reasoning for not doing anything I saw was "no one uses this". Sure thing, given it's barely usable.)
You can add multiple client sertificates to a single account for example in case of git hosting services. Why would it be impossible for other services?
I'm not a big fan of Steve Gibson, but his SQRL project looked very promising to solve the issue of passwords and password storage (both user and server side).
I was thinking we could build a general purpose version of "Magic Links" for logging in, where the format of the email is well-defined, and the user's browser is able to receive these messages on their behalf through some form of integration. You could imagine a webmail provider offering some kind of polling or websocket API for listening for when these messages arrive.
When the site they're visiting indicates through its web page that, "I'm trying to authenticate you by email", then the browser can fetch recent incoming messages of this type, then parse them and display UI chrome like "Xyz.example.com wants to authenticate you". You click a button to log in passwordlessly, which involves sending an HTTP request to a link specified in the email. Coordination occurs on the server side and the login is allowed.
There are probably some details I'm not considering, but it doesn't seem like it'd be too hard to build a prototype, and if standardized and deployed it would eliminate the need for passwords. I gather that Mozilla Persona works along similar lines, though I confess to not knowing the exact details. There would be practical difficulties integrating all of these things together, though: email, browser, and website login, and gaining adoption in the real world.
There are also sites that don't require email on signup, but this feature could be supported only for people who want to supply email. The email address used for this feature could also be a different technical address unrelated to the primary mailbox, where only login requests are sent. This could also help expedite the email traffic to ensure it's real-time. The browser could automatically fill in the email address when challenged by a website supporting this login method.
Alternatively, perhaps a browser vendor could introduce a de facto standard where sites can integrate via an API with the browser's password safe features. Chrome can save passwords and synchronize them across devices. Maybe it wouldn't be too hard for sites to comply with a microformat that helps the browser understand when to generate a password on signup, and when to provide it, etc.