By Zed A. Shaw

I've managed to get Autho.me working to the point where there's a functioning API and a full Python demonstration web site that uses it. The API is very simple right now, but it should work and the mechanisms should all be solid enough to try out. I've got the SRP javascript code to check all the various failure modes required, and have thrashed it good, so it should hopefully hold up to scrutiny.

If you want to try it, just go to the getting started instructions and they'll tell you how to get setup. It's a single page of docs so to find out more you'll need to look at the code and check it out.

Big Ass Warnings

Do not use this for anything serious yet. I still have to do a few attack decision trees analyzing possible attacks and then handling them. I'm going to work on a spreadsheet that lays out attacks to standard website, autho.me, oauth, and openid. I'll be using this decision tree to figure out what needs to be handled and what can't be handled, and also to make sure that Autho.me is at least as secure as OpenID or well done site login system. This attack tree will also drive the design and UI of Autho.me in the future.

But until I've done that and got the crypto checked out you shouldn't use this for anything serious. It's probably more secure than whatever crap login system you've cooked up (especially if you're storing passwords in the clear), but don't trust it yet.

Actually, you should not trust any of these login systems, but that's not very practical.

This is why Autho.me is NOT USING SSL. This lets you look at the entire protocol and check that it's working right, and also keeps you from using it for anything serious.

You've been warned.

How It Works

The API is really just four API calls:

• /API/register_start -- Get stuff you need to start a registration.
• /API/register_finish -- Finish the registration.
• /API/auth_start -- Get stuff to start an auth.
• /API/auth_finish -- Finish the auth and see if it worked.

It's broken up like this because of how SRP works, and it's the minimum API calls needed. It is also written in a functional style rather than RESTafarian dogmatic. The way this API works you should be able to use it from just about every HTTP client on the planet.

You gain access to the API by registering a Customer Account and then using the passkey you get. In the future you'll be able to make as many passkeys as you want, so you can setup central management for a bunch of sites and users get put into those keys.

Your web application is basically a purposeful man-in-the-middle that's proxying data from the browser to Autho.me and back, but checking the results as they go by. Since both sides (browser and autho.me) are verifying that the SRP is established and proven you get to see if the user authed correctly, and that the Autho.me server is working.

That's really all there is to it. There's a few actions for disabling, enabling, and checking the access of an account, but that's minimal and should get more features.

Customer vs. User

In order to keep everything straight in my head, I have Customers and Users. A customer is someone who has registered on Autho.me and then got a passkey to authenticate users. A User is someone who's logging into a site created by a Customer.

In Autho.me the service trusts the Customers more than the Users. It's assumed the Customer is running a site and that users are logging into it for some valid reason. It doesn't try to protect against phishing attacks or untrusted sites, since no service can protect against that. Phishing and untrusted content is a browser usability problem, not a protocol problem.

By comparison, OpenID assumes the User and a Third Party is more trustworthy than the Customer. I personally find this bizarre since it's saying that someone is going to log into a potentially dangerous site, and simply using OpenID makes that alright. That's the difference in the design.

There's some interesting competition between the User and Customer too. For example, it'd be very easy to let Customers trade User accounts for things like bundled cloud service sales or User portability. However, this brings up the issue of who owns an account. If Customers own the account, than this is totally alright. If Users own the account, then this is totally wrong.

I'll have to think about resolving issues like this, but most likely it'll be a social/marketing problem and not so much a technical problem. Right now copying a User between Customers is just a simple copy operation.

Future Improvements

Definitely need to get a better UI on this stuff. The backend and javascript was hard enough that I just threw up whatever made all of it work. The next phase will be coming up with a good set of best practices for usable logins, and coming up with a better design for autho.me.

After that I want to get two factor authentication going using Twilio for SMS. I'm envisioning an extra API parameter that lets a site pass in the user's phone number (I won't store it). Autho.me would then send an SMS with a 5 digit number in it that the user has to enter along with their password. This will get included in the proof the client sends to complete the authentication.

The most important thing though will be doing the attack decision tree and getting the crypto validated. I've tried very very hard to not write anything myself, and just used Tom Wu's projects, but I'll want to make sure what I got works. Problem with that is it will probably take money, which I don't have.

Finally, I'm doing a Sinatra+Ruby style demo next. Pretty much exactly the same as the Python demo, just using Ruby.

Request For Comments And Bugs

I've setup a support system where you can punch in bugs you find, or requested features and gripes about the service. Anything is up for grabs, so enter them in and I'll try to deal with them.

Thanks.