First released earlier this year, Persona offers a secure way to eliminate individual passwords for users while offering developers a simple way to add support and authenticate requests—think of it as OpenID without the headaches.

After seven months of morphing APIs and various Persona improvements, Mozilla has deemed the project “ready to use for authentication.” Persona works in all major desktop and mobile browsers and, according to Mozilla, the user experience has been considerably polished for this release. While Mozilla claims it’s ready to use, bear in mind that Persona is still officially a beta.

Mozilla Persona is a distributed online identity system. It’s part of Mozilla’s effort to tackle online identity management by shifting the focus from individual websites to a decentralized system that sites tab into.

Mozilla has been playing with the idea of a browser-based identity manager for quite some time, starting with its BrowserID project. BrowserID is the foundation of Persona, but the new system offers quite a bit more for both developers and users, including user-friendly features like an “identity dashboard” for managing your various credentials.

So, instead of the minor security of having several different ID & password combos, leaving you with some protection if one of the combos gets found out, they want you to trust them to hold a single ID to use everywhere? Yeah, no thanks.

One important thing to know about the beta release of the Persona system is that all login authentications go through Mozilla's remote verification server. So it is currently similar to other federated login systems where the login provider is able to track every site you log into.

This is not the intended design of BrowserID (the open protocol that Persona is based on) -- these authentications are supposed to be handled by the server of the website you are logging into -- but that part of the protocol is still in flux at the time.

Personally, I think they should have waited until that was nailed down before the beta release, and then shutdown the remote authentication servers altogether when the 1.0 release occured. As it is now, they will have to keep those servers running when they release 1.0 to continue to support the websites that adopted Personas while in beta, so users will have no idea which sites are authenticating them locally and which are using Mozilla's servers.

Apart from that, BrowserID looks like it will be much better than OpenID in every regard (usability, privacy, security) once it reaches it's final incarnation.

How is this secure? So what if there's a wall between me and the site I am logging into. If my password for persona is compromised then that person can sign into all of my persona accounts. How easy would it be for someone to spoof a browser id?

How is this secure? So what if there's a wall between me and the site I am logging into. If my password for persona is compromised then that person can sign into all of my persona accounts. How easy would it be for someone to spoof a browser id?

Pretty much all of your accounts can already be accessed if your email password is compromised, so you aren't any worse off using Persona than you are now. It is not possible to spoof BrowserID certificates, but is may be possible for a temporary one to be obtained via MITM attacks, or a permanent one if your identity provider is hacked and their private key is obtained (without their knowledge, otherwise they would revoke it).

So, does this means I'll be able to fight shadows? (For those that get this reference, your geek cred just went up by 50 points).

This seems to match up a little bit with my thoughts on a global two-step authentication process to log you into everything. I'm not entirely sure how confident I feel with how secure this is, but it is a step in the right direction.

So, instead of the minor security of having several different ID & password combos, leaving you with some protection if one of the combos gets found out, they want you to trust them to hold a single ID to use everywhere? Yeah, no thanks.

Most users don't use several different IDs and password combos, which means in real life that when one website gets hacked, that users accounts *everywhere* are hacked. It's unrealistic for us to expect those users to start using lots of different passwords, given that we have a hard time getting them to come up with a single secure password.

Thus, not having a password stored on 400 websites is far better for security in the typical use case.

For people who do maintain a huge list of usernames/password combinations this isn't better, but those people are a small minority.

I assume this is based on 2-way SSL and certificates, but the certs are handled by a third party. I'd much rather generate and manage my certs for my clients. The problem is the browsers don't have a standardized and seamless way to load the signed client certs.

How is this secure? So what if there's a wall between me and the site I am logging into. If my password for persona is compromised then that person can sign into all of my persona accounts. How easy would it be for someone to spoof a browser id?

Pretty much all of your accounts can already be accessed if your email password is compromised, so you aren't any worse off using Persona than you are now. It is not possible to spoof BrowserID certificates, but is may be possible for a temporary one to be obtained via MITM attacks, or a permanent one if your identity provider is hacked and their private key is obtained (without their knowledge, otherwise they would revoke it).

I would have thought not necessary so. What if you're consistently using aliases? Not a fan of central repositories though.

So when is Firefox supposed to support BrowserID itself? That will be reason enough for me to switch back. Also, does the spec allow for 2 factor verification? Because that is a minimum security measure, especially since it will be holding all our data, IMO.

I would have thought not necessary so. What if you're consistently using aliases? Not a fan of central repositories though.

Aliases provide some security through obscurity, in that dumb automated hacking scripts might not try common aliases when trying a cracked password at different sites. You can use email aliases with BrowserID, and it will provide that same (minor) layer of security. The fallback identity provider of the persona system (login.persona.org) will support any email address, so aliases would work the same as it would if you had multiple email addresses and used them at different sites. Alternately, if your email provider is setup as an identity provider, it would be up to them if they supported aliases.

Quote:

Also, does the spec allow for 2 factor verification? Because that is a minimum security measure, especially since it will be holding all our data, IMO.

There is no reason that identity providers can't require 2 factor authentication when providing the certificate that authenticates you to the website. That part of the process plugs into whatever existing authentication system they are already using.

Silly me, I thought this was about Mozilla Firefox Personas. I was wondering what it had to do with logins and why it would be going beta. Hooray for confusing duplicate names, especially from the same company.

Silly me, I thought this was about Mozilla Firefox Personas. I was wondering what it had to do with logins and why it would be going beta. Hooray for confusing duplicate names, especially from the same company.

I was just about to post this. They probably should have picked a better name than Persona.

So, instead of the minor security of having several different ID & password combos, leaving you with some protection if one of the combos gets found out, they want you to trust them to hold a single ID to use everywhere? Yeah, no thanks.

You don't use it everywhere, you only use it in places where the amount of security it applies is appropriate.

I haven't looked into Persona yet, but I do use Open ID. The way that works is, instead of a site asking me for my username/password, I enter in my open id (I purchased a short domain for it... "abhi.id.au"), and then the website contacts that URL to ask if it thinks I really am that person. The server at the URL is responsible for deciding how it authenticates you, so the user is in control of choosing one that has strong enough security.

My Open ID currently has a nice strong password (I can't remember it) and a public/private certificate keypair installed in my browser that authenticates me. Instead of typing in my email and a short/insecure password every time I wanna log into a random blog somewhere, I type my short open id, click a button to say "yes, i'm OK with this website knowing that I am abhi.id.au", and that's it. I'm logged in.

Thanks but no. The last systems that claimed it was unhackeable LastPass was also compromised at least in some levels.

Technically, Lastpass is still unhackable. Or at least I should say uncrackable. Whatever compromise they had on their servers resulted in absolutely nothing happening. And even if passwords were somehow leaked, the amount of time it would take to bruteforce the encryption/hashing algos that they use could be measured in the tens if not hundreds of thousands of years.

I have no idea if Persona works the same way in regards to security, but I consider anything less than what LastPass does to be completely amateur.

Most users don't use several different IDs and password combos, which means in real life that when one website gets hacked, that users accounts *everywhere* are hacked. It's unrealistic for us to expect those users to start using lots of different passwords, given that we have a hard time getting them to come up with a single secure password.

I'm not entirely sure about calling it unrealistic; I think the problem has been that there's been too much of a push for too long to emphasize complexity of passwords (use upper and lower case, use numbers, use special characters). Too often users would create a password that was hard for them to remember but relatively easy for computers to guess.

A more sensible approach is 3 or more common words, randomly chosen, separated by a space (which acts like a special character). Thomas Baekdal proposed this in 2007 with an article called The Usability of Passwords and Randall Munroe summarized that approach in xkcd webcomic #936: Password Strength

Lots of information there (warning, this is me plugging my own blog as follows:) so I summarized it up for friends and family here.

I think this approach is realistic and easy to explain. LastPass and similar password/data managers still rely on a master password and it's possible to get a user to come up with one that's secure with that approach. I do admit that it might be difficult to discourage the average non-tech-savvy user to stop using their favorite services for authentication (thereby using the same password multiple times), but I think we need to.

Baekdal does talk about server security, and basically he says that users need to practice good security on their end, because they can't control a server being hacked (like a hacker downloading a server database and plucking passwords from there). That's the job of the server administrator, of course, using good encryptions such as salt and hash methods. In those instances, complexity has it has been explained for passwords generally IS important.

pavon wrote:

Not decentralized yet.

One important thing to know about the beta release of the Persona system is that all login authentications go through Mozilla's remote verification server. So it is currently similar to other federated login systems where the login provider is able to track every site you log into.

This is not the intended design of BrowserID (the open protocol that Persona is based on) -- these authentications are supposed to be handled by the server of the website you are logging into -- but that part of the protocol is still in flux at the time.

That concerns me a bit. I mean more with the idea that the burden of trust is with the server... and as I said earlier-- individual users can't really control things being compromised at the server level. It is also my understanding that OpenID and BrowserID are designed primarily with privacy in mind. At least, that was my impression when OpenID started to be widely used, and quickly glossing over Mozilla's press, BrowserID is more implicit about not tracking user history. Privacy and security are not necessarily the same thing, although I'll freely acknowledge where they subset.

I don't mean to imply that the standard isn't useful. But I would be concerned if the general public embraces Mozilla's standard to the detriment of good security practices.

Having a master password stored online is just a recipe for disaster. That is the weak link for many of these password aggregators.

Personally, I use a program that I can put on a USB key and carry around with me. It stores my passwords locally, in an encrypted file that I can access through the stand-alone executable. I never have to worry about someone hacking into a central repository (but do have to sync the bloody thing with my main PC from time to time).

So, instead of the minor security of having several different ID & password combos, leaving you with some protection if one of the combos gets found out, they want you to trust them to hold a single ID to use everywhere? Yeah, no thanks.

Are you making an off the cuff comment based on the Ars story? Or did you ACTUALLY go look at how it really works?

So, instead of the minor security of having several different ID & password combos, leaving you with some protection if one of the combos gets found out, they want you to trust them to hold a single ID to use everywhere? Yeah, no thanks.

Are you making an off the cuff comment based on the Ars story? Or did you ACTUALLY go look at how it really works?

I went to the Mozilla site and read/watched a few things, but they lacked meat. Can you suggest some more informed references please?

"One major issue I noticed was that once your browser has an assertion that you own a specified email address, you are no longer prompted for validation (until I assume the time the assertion expires). I'm not entirely sure if this is just the way it's been done for the demo or if it's the expected norm, but this is bad. Very bad. It may be convenient, but I don't believe the benefit outweighs the security risk posed. Why? Because it gives anyone with access to your web browser full access to all the sites you use BrowserID for without having to know your password. You are simply asked which email address you want to use and if the relying party site accepts it, you're in! Bad bad bad! I'm not aware of any written guidance by Mozilla on when assertions should expire (although I must admit I have not read ALL their documentation), but I hope email providers choosing to support BrowserID set short assertion validation lifetimes.

It's still very early days for BrowserID so it's difficult to be too critical. "

Time will tell. There are benefits, but also risks e.g. you best make sure you have a good logon and screensaver wake password to keep people out your computer because if they can get in your browser then they own you. Given what we saw with the Mat Honan attack, personally I am now very wary or linking any account with a single logon!

Time will tell. There are benefits, but also risks e.g. you best make sure you have a good logon and screensaver wake password to keep people out your computer because if they can get in your browser then they own you. [/sarcasm]

That better be an encrypted drive, if you have physical access, logon and screensaver passwords are minor roadblocks to an account's data.