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.
Actually the problem is already solved for at least a decade: Certificate based authentication. Browsers support it. Try StartSSl registration, for example.
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?
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.
I tried getting one myself a few years ago, and I couldn't. The process was too obtuse and obscure for me to follow along the entire way.
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.)
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.
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.
Don't need such service now, but I had accidental necessity in past few years.
(Also, please consider submitting it to HN when you go live.)
I will submit a Show HN. Thanks :)
- whatever solution we come up with needs enough market force to push adoption
- whoever gets to own "single sign on" owns the world. This is why there was so much backlash against Microsoft Passport all those years ago.
Personally I'd favour some sort of hardware token, and we're very slowly moving in that direction with U2F.
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.
The important bit about that is that the Last.fm/Audioscrobbler account credentials get typed directly into the third-party players - usually there's no browser involved in authentication, and in some cases the players will also be on a mobile device.
There's a definite incentive for passwords to be simple (if you're going to type them in on a mobile keyboard) and weak (because it's just music metadata).
So, a 'magic link' style of logging in might work here, but it would have to be complemented by an easy way of generating auth tokens for player apps - for instance, short one-time-use codes that expire quickly.
Copying and pasting links isn't that hard. Go to last.fm, generate OTP token/link, paste into Spotify. Done. I should have some easy way to identify authenticated apps under my account and kick them out, or reset all.
Not all of us use Web mail. And I might not want a link automagically opened there and then, under a browser.
This isn't even that greater of a concern; it currently is in 99% of cases the method for password reset anyhow.
That is already the case for the supermajority of people. They use one email account for everything and you can simply "Recover Password" on various services once you gain access to their email account.
Not many people purposefully use unique, individual email addresses for every single service they sign up for...
When they do, generally email for all of them ends up in the same account anyway.