Identify with email: no need for passwords
medium.com
medium.com
EDIT: In fact, Persona goes one better. Persona has the browser act as an intermediary between your e-mail provider and the site that you're logging in to, so that the e-mail provider doesn't get to see the source of the authentication request, and the site that you're authenticating with doesn't get any further details beyond your e-mail address.
This is noticeably unlike OpenID / OAuth[2] / many name/password systems, where you can revoke access to specific tokens / sites on the ID provider, and where many username/password sites reject all old cookies after you change your password. Anyone with your token / cookie / etc will immediately lose access with this, and the provider can prevent new sites from using old login info.
[1]: and remember that they don't "phone home" to the Persona provider, so there can't be any rate limiting. virus -> botnet -> millions within seconds is totally possible, if unlikely and costly.
[2]: yeah, OAuth ain't an ID system. same basic structure though.
The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed.
Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into.
So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it.
Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)
You're right, Persona is safe from e.g. MITM attacks. Really, it's a good structure, I like it. But as usual, a virus means game over, and in Persona's case its structure means game over in a uniquely crippling way that you really can't protect against. That's the tradeoff for your provider not being able to watch where you log in.
If I never reuse my passwords, or use e.g. an external tool (something like a yubikey, though I can't speak to that one in particular), the worst a virus can do is steal one site at a time. If a virus steals my OAuth token, it can be revoked. If someone gets my OpenID login details, hopefully my provider would notice something is up when requests start coming fast and furious, and start rejecting them.
And all of that is just as secure against MITM as Persona if I run it through SSL.
This is of course assuming no 0-day on the device / my webcam to snap a photo of where I wrote down all my passwords on post-its and stuck them on my laptop. But browser 0-days aren't all that rare, and viruses certainly aren't.
As we've seen with a bunch of high-profile compromises, the email account is already an extremely valuable target for attackers. Another good reason to enable 2-factor auth there!
Now say they get your Persona email account, and get the signing material from it once. They can now log in everywhere until that material expires. There's nothing you can do about it. THAT is very different.
There's a small thing you could do to mitigate this, but really only self-hosted email has it as an option: change the email server's keys. You would be able to block logins to any site which has not cached those keys.
But no big provider would do it for you, since it would break everyone's currently-live keys, and from what I can remember they recommend that sites using Persona login cache the keys[1]. So any site you had logged into may very well have cached them, and not even perform a web request, and still allow the malicious login.
--
The only real way to dial back this damage is to limit the lifetime of the original signature. Make it too short and slow internet connections can't log in anywhere, and browsers have to continually request new assertion-signing data. Make it too long and you let attackers try many, many, many more sites.
[1]: I can't find this on the Persona/BrowserID site :/ maybe it was in a presentation somewhere. Anyway, it's inherently cache-able material, and it is a great selling point - server-side web requests are painfully slow.
On our internal Persona IdP (for mozilla.com and mozillafoundation.org email addresses), the signature is short-lived (a few minutes I think). The browser will therefore need to request a new signature very often. This can happen transparently as long as you still have a session with the IdP and that session can be invalidated server-side in case of a compromise (or a password change).
Viruses kill, they were created for that.
But since you mentioned it, I think the risk of malware exists and will continue to exist even if you are using passwords
Think key loggers.
Key loggers only get what I type in. And the value of the material they logged is lost as soon as I change the valuable bits without it being logged. Easily enough done with a phone call to my bank or a friend's computer or a clean install. I use unique passwords everywhere - I can prevent extensive damage with that alone.
(edit: also two-factor auth / one-time-passwords almost totally nullify keyloggers)
Lose your Persona signing key, and you can't stop it. It lives as long as the key claims to live. Imagine someone stole your credit card and is making massive purchases, but there was no way to cancel it, it would just continue pulling from your account until the expiration date on the card. Now tell me why that doesn't concern you when compared to e.g. someone stealing the cash in your wallet.
But Mozilla's servers (or the email provider, but I don't expect to see any significant uptake of this feature) get information in the HTTP requests, whether they like it or not, and they're based in the US.
1. JavaScript shim 2. include.js 3. Centralized verifier 4. Fallback identity provider
However, we've designed the protocol so that all of these pieces (necessary to bootstrap the system) will go away over time.
#1 will go away once we have native support in the browser (some of our developers have starting working on this). #2 will go away once we make include.js self-hostable, which we are definitely planning to do. #3 will no longer be needed once sites can use local verification libraries, which we have started writing. #4 can already be avoided if you put up your own identity provider (several people have done so).
Right now, our fallback identity provider (for email providers without native support) requires that people set a password to avoid having to confirm their email every time. However, we're currently exploring the idea of making the password optional and letting users click an email link at every login, just like the author of that article suggests.
I don't think it works for everyone, for example some people read their email on a different device, but it would certainly work for those who always keep their webmail open in a tab.
BUT, it would drive me nuts if I had to do that every time I logged into my bank, for example, because sometimes e-mails take 1-2 min to arrive, very occasionally even half an hour. They get queued up somewhere along the way, who knows -- maybe the spam filter's being overloaded. Sometimes your organization's e-mail simply goes down. Sometimes your webmail goes down. Heck, sometimes your e-mail gets inadvertently disabled.
If it were instantaneous, and your e-mail account always worked perfectly, then it would be great. But the way things are set up right now... this isn't a viable option for a lot of sites. And it's certainly not going to replace your e-mail password ;)
I wouldn't use this feature on every site but there are some sites I use infrequently enough that virtually every time I use them I have to do an email based password reset anyway, which is often implemented in a way that makes it a very clumsy version of this system anyway (since following the reset link often gives you a valid login cookie).
For the most part I consider email to be unreliable. There are simply too many things that can go wrong. I'm also amazed that there hasn't been some kind of messaging protocol to replace the damn thing (throw it on top of http even). I guess spam really ruined it for everyone.
Also, add to the fact that this is a novel method, I get a lot of emails asking why they get new passwords everytime. If I were to rewrite FtC today, I'd go with Persona.
That's because SMTP (the protocol that moves email around) doesn't guarantee delivery in any specific time period. Many MTAs (message transfer agents) are configured by default use retry intervals measured in minutes, not seconds.
Relying on email for authentication means asking your users to wait minutes, not seconds, and asking users to wait minutes to get logged in to your website is horrible usability.
Yup, I'm one of those people.
I don't use Facebook, and it's unreasonable to expect me to sign up for a Facebook account so that I can use your service.
I do use Twitter, but I'd rather not share my account details (even just the username) with someone I've just met.
I've always thought that being able to explore the web of information out there about me was kind of creepy, and I'm not about to make it easier for someone to do by creating connections between the accounts I have with disparate service providers. I like when my data is siloed, and only shared on my terms, with my explicit consent.
Better to create separate accounts on each site and minimize dependencies. Also, if you lose your facebook password, it's just your facebook account that'll potentially get affected.
From a user experience point of view, it's much more effort (at least 3 clicks more) to have to open an email client, open an email, and click a link, as opposed to just entering a password.
Also as airlinenut mentioned, it would allow others to send you an annoying email just by entering your email address, and any methods to prevent this (captcha etc) will just make it even harder for the user.
This sentence implies to me that under the current system, sites need cryptography, because sending login information in plaintext is not secure enough.
...and that the solution is to use email, because we already treat it as if it's secure.
...even though it sends the data in plaintext.
Okay, so most end-users probably accesses their email via https these days, but it's a (potentially) long journey from the website to the email provider's server.
Is any of that server-to-server journey ever encrypted? I'm no expert, but my impression has always been that it's not.
It can be, thanks to RFC 3207 (STARTTLS).
However, unless you configure your sending MTA to require TLS (and in turn give up the ability to send email to a large swath of the internet) you have no protection against a MITM adversary hiding the recipient's advertisement of STARTTLS.
It is also worth pointing out that a number of sites allow passwords to be reset via email, and so an attacker who can read your email can potentially gain access anyway.
My take-away is that it is probably better to go all-in on one approach (all email-based or regular logins) than a half measure. It is kind of interesting because it seems to cause trouble for users that are semi-technical; the ones that know how a username/login works in general, but are thrown for a loop with this whole "email is how you login to our special app!" thing. Super technical users understand and super newbies don't really seem to notice, but those middle ground users are a bit confused.
This is already how most websites work isn't it?
The net positive, if this were implemented across the board, is that users would focus their efforts on securing a few high value accounts, versus reusing the same password across dozens of low value accounts (chain, meet weakest link).
Login email delay increases exponentially with each request.
You could have one email account in which case it becomes the single point of failure / attack and you are only as secure as that email provider.
Or you have multiple email accounts in which case you have multiple email account passwords to remember manage. You might as well have multiple site passwords
Uhh.. I sure hope the cookie tokens are not stored directly on the server-side, but rather verified against a (cryptographic) hash of same. These credentials are as valuable to an attacker as a password (albeit relatively short-lived).
A combination with email confirmation plus two-step verification like Google Authenticator could work as well.
They provide businesses and organisations an authentication service for their customers. The service is enabled for all web applications, and can be accessed from any user device. PixelPin replaces the current password solution which is expensive to manage and full of vulnerabilities with a very user friendly and memorable solution that uses personal pictures from the users own device as a means of authentication. The service is very secure and maintains the users privacy. Once a user has completed the simple process to set up a PixelPin account, they can then login to any PixelPin enabled web service.
Info and the Dev pages at https://login.pixelpin.co.uk/Developer/Index.aspx for tech integration info. Integration can be achieved in 2 to 4 hours.
By the way Windows 8 can not do this, but PixelPin can replace Windows 7 and 8 login