Hacker News Reader

Comment by callahad | Hacker News Reader

It's decentralized public-key based authentication, wrapped up in an extremely user- and dev-friendly package. Francois Marier did a good job of explaining it at Kiwi PyCon 2012: https://www.youtube.com/watch?v=iZBTc7iEkQY

(Think OpenID, but easier to use, easier to implement, and with better privacy protection.)

In brief: instead of a username and password at login, you get a user's email address and cryptographically signed assertion proving their ownership of that address. The assertions are ephemeral and scoped to your site, so once you verify it, you can set a session cookie and throw away the assertion. No more password column in your database, yet you still retain a direct relationship with your users.

Here's the underlying spec (working on getting it updated for Beta 1, but the principles are all there) https://github.com/mozilla/id-specs/blob/prod/browserid/inde...

View on HN

Congratulations on this and thank you. The links are useful and I recommend the video-I got a proof of concept onto our staging servers whilst listening to the video - fantastic.

Can I suggest a clearer explanation in the quick start guide of loggedInEmail and it's options and that there is a comparison of the name supplied from the site and name inside the browser - it is a bit confusing to see onlogin get called without a button being pressed. I would suggest walking a dev through what to expect - the code examples are great but the quick start is written by someone who understands what's going on behind the scenes - there is a sentence About currentusr that completely floored me - I could not understand how I was supposed to know bob was logged in if that was the first time he arrived at the site. In the end I gave up and read the docs !

Edit - needed bigger text box on ipad

>No more password column in your database...

Who has liability when a user of mine says their account got hacked? The email provider? My site? Mozilla?

If one of my users has $100 go missing from their account, then they are going to expect me to replace it, not the email provider, not mozilla. I don't like the idea of shifting security to a outside platform, because I still retain all the liability when things go bad, and they always will (key loggers, spyware...)

Sites that deal with financial transactions will be reluctant to adopt this for sure.

For financial items you could use two factor authentication. Or if your service has something that can be done with a lower set of privileges you could use persona there and fall back to "more secure" methods for anything with financial effects or account changes.

The use case seems to be more for sites like twitter, hacker news, reddit, etc...

Sites that deal with financial transactions are almost always 5-10 years behind on the adoption curve; of course they will be reluctant to use Persona. And that's not unreasonable.

How can any website protect a user against key loggers, spyware or any other form of a compromised client machine? If the client machine is compromised, any login method is broken.

As mentioned above, two factor authentication.

Not really. All 2 factor authentication schemes that I've seen give no protection against a compromised client machine.

In theory you could probably device a scheme that would require the use of two independent devices to perform any sensitive action and that would guarantee that if only one of the devices is compromised, the attacker would have no way to perform any action in a name of the user. But I'm afraid any such scheme would be a complete failure from a usability perspective.

When the second factor is a "rich" device, such as a smart phone, attaching transaction information to the interaction would be a trivial - instead of texting "The code is 1234", text "Transfer $100 to account 9876" or "Login attempt from IP 1.2.3.4, FooCom Inc, Springfield, Oregon, USA.", followed by "If correct, enter code 1234. If not, DO NOT enter the code and contact us at .. "

Reply on news.ycombinator.com