They are cleared the same way as normal cookies: they are visible in the cookie manager where they can be manually deleted, and they are generally included in all of the other cookie-clearing mechanisms.
> did you evaluate various information sources (Ghostery, etc.) before settling on Disconnect?
Monica Chew, the engineer who did the bulk of the work on this feature, did consider a number of available lists before settling on this one. The Disconnect list was the best freely-licensed (GPL) one at the time. Also, they now have a web form to let users suggest new trackers to block (https://disconnect.me/trackerprotection) so it should get even better.
> Does anyone understand why Mozilla publishes valuable information like this over random personal blogs, rather than a central place like a knowledge base (e.g., a wiki)?
It's pretty tricky to share information in the "right place" because of the amount of information produced by everyone at Mozilla. Someone's preferred channel is often another person's blind spot.
How ironic that I only discovered the information, present the whole time in the wiki, via your blog!
Thanks for taking the time to respond and to write up the blog post in the first place. I hope what I wrote was taken as intended, referring to general practices and not to your efforts.
I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions.
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 :)
Or you just have a virus that searches the RAM where the browser sits. Or a deliberately compromised browser.
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.
I assume you are using the term virus interchangeably with malware.
Because the purpose of a virus isn't to steal or wiretap your device, it's sole purpose is to destroy.
That being said, if you happen to get a virus then your device will most likely malfunction, certainly it's possible that a virus steals information but that's a long shot.
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
Yeah, virus/malware/choose your term. I'll happily settle for 'malware', it's descriptive.
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.
One thing to note as well is that if a virus steals your email password, then you're a bit screwed too because that can, in most cases, be used to reset your password on other sites.
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!
Yes, but, if you change your password / answer your security questions to get back in you get control back.
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.
Yes, your best protection is a short-lived signature on the user's public key. That's up to the identity provider to decide.
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).
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.
The fallback identity provider (at login.persona.org) does use email for password resets, but other identity providers will likely use other mechanisms.
I hope so, but why not do the right thing in the default identity provider?
Lately, there have been tons of high-profile hacks that boiled down to taking control of victim's email and resetting passwords to other accounts. What's seems to be the best response possible from web developers? Is it:
a) Demand that all your users use Gmail with enabled two-factor authentication, then smugly blame them for all security issues if they don't.
b) Stop using emails for password resets, since you don't really know how trustworthy your users' email providers are.
One of the ways crackers gain access to a user's email is by guessing their password, a simple task when a huge number of users use the same password everywhere. With Persona, only your email provider (and the persona.org fallback) have your password (two passwords in the case of the fallback), hashed or not.
If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, Persona isn't an improvement in security. If you don't, as most users don't, Persona makes authentication more secure and more user-friendly at the same time.
With Persona, your weakest point would still be your email provider, which is why it would still be wise to recommend two-factor authentication for your email.
If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, AND you have enabled two-factor authentication with your email provider, Persona IS an improvement in security. This is because, with Persona, having two-factor authentication for your email would automatically mean two-factor authentication for all your websites as well.
I use Two-Factor Authentication across a lot of my accounts. I feel a lot more secure when I can telesign into my account. If you have that option available to you use it, it is worth the time and effort to have the confidence that your account won't get hacked and your personal information isn't up for grabs. If you opt into 2FA, you will have to "Confirm your phone". You would receive a text message with a specific code to be entered into the system. If you don't want to do this every single time, you can designate your smartphone, PC, or tablet as a trusted device and they will allow you to telesign in without the text code. Should an attempt to login from an unrecognized device happen, it would not be allowed.
Your last point is not completely accurate; with Persona and 2-factor auth on your email account, you would then have verified ownership of your email account via 2-factor authentication. This doesn't mean that every assertion generated by your Persona account will have been generated with 2-factor auth.
Because it's not the "default" identity provider, it's the "fallback" identity provider.
They're trying to define a open standard which would end up with any number of identity providers. The goal is something that can bootstrap the system into usage.
As far as what to do about users? You can't fix the problem. Nothing is going to be 100% secure, and the flesh is always going to be the biggest weakness if the machine has been well designed.
If you really want conjecture on it, though, I would suggest you first ask "Is this something tied to a citizen's identity, or a online identity?", because most things that process fiat currency in any capacity will fall into the former, and should probably merit a recovery system outside of email.
I would argue, however, that anything falling into the latter and should be handled with email.
Public key crypto has many usability problems, but it solves a lot of other problems. I wish some of the big mail providers like Google would throw some money and people at it.
That depends on the kind of services they provide. Simplest options that come to mind are nothing (like this wesbsite) or a printed reset code with owner notification on use and 1-day wait period. At the very least they can allow power users to disable password resets when they want.
Nothing is extremely painful for a federated identity protocol (although I think it should be a clear option for those of us who take these things seriously!). Printed reset codes are part of the way there, but how many people will actually save or print out the file?
SMS confirmation is another mechanism, and one that is viable in most of the world, but has a different set of risks.
I think a combination of these are a good approach, but this is a really tough problem in the identity space, and if you have any suggestions on how to improve it in a way that is viable for a large user base, your feedback would be greatly appreciated!
Logging into a different device is not a problem, you just get a different certificate in that device's browser and it allows you to login in the same way.
When you use a computer that's not your own, Persona keeps the session time very small. Of course, when you're done using that computer, you should ideally clear cookies, just like you would if you used OpenID or Facebook on a shared computer.
They are cleared the same way as normal cookies: they are visible in the cookie manager where they can be manually deleted, and they are generally included in all of the other cookie-clearing mechanisms.
You can find out more about the ways to control cookies in Firefox here: https://feeding.cloud.geek.nz/posts/tweaking-cookies-for-pri...