Auth module exploration

[gsf]

We need to either find or build an authentication module. It should have a RESTful JSON API. We're thinking single sign-on following the OpenID spec.

[gsf]

Might be worth reviewing the list at http://wiki.openid.net/w/page/12995226/Run+your+own+identity+server.

[gsf]

Okay I was thinking an openID server would be cool but then I scanned the following:

• http://openid.net/specs/openid-authentication-2_0.html
• http://en.wikipedia.org/wiki/OpenID

And then I read the article and comments here:

• http://news.ycombinator.com/item?id=4164159

Now I'm thinking we should just do a simple authentication service. Send username and password, get back authentication token if we have a match. Or we could really jump ahead of the curve and try to implement a BrowserID server.

[hackartisan]

an interesting / potentially useful specification http://slide.blorkmark.com/

[hackartisan]

this should also be here: http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/

[tmmagee]

How about this scheme:

Instead of our auth app checking against a username and password (which would make it an auth app specifically for user validation), the app will check against a single hash that would represent a kind of "EntityID."

Example: In MESS users would log in with a username and password. MESS would need some algorithm for generating the "EntityID", and in turn would pass that to the auth app. The auth app would then check the EntityID passed in against its database, and return YES if the entity exists and no if it does not.

The auth app would of course using hash the EntityID again before storing it in its database.

This scheme would allow our auth app to be useful for any app that is capable of generating an EntityID, and each app that uses the auth app would be responsible for generating its EntityID using whatever parameters are pertinent to that app.

[tmmagee]

Okay. I have one question the EntityID idea listed above: will the auth app be responsible for ensuring that no two usernames are identical, or will this be handled in the user's app?

[gsf]

I like this entityId idea, Tom -- very simple and flexible. As for unique usernames, the user management app would be responsible, which makes sense. One neat thing we could do with an entityId is store it in the session once the user has logged in, then use it again to authenticate the user if they go to another app in our system, bypassing the need to log in a second time. Single sign on!

[hackartisan]

• Good way to do Single sign on (SSO) would be to give back a randomly-generated token which the app can set as a cookie (with reasonable expiration) in the user's browser. Auth module API would need to accept this token, return OK if the token is still valid.
• Re: EntityID. We may be generalizing beyond a useful point. One thing we lose is the ability to attach a timestamp to the request, which I like as a security measure. (If you don't send the username separately, but do use a timestamp, there is no way to tell which entry to check against.)
• Also, if we send username and password, the client doesn't have to hash things which is nice.
• note to selves: don't log passwords.
• on sending passwords over SSL: http://security.stackexchange.com/questions/7057/i-just-send-username-and-password-over-https-is-this-ok
• on sending passwords: it may still be good to hash them to avoid logging by parent app as it's sent to auth module.
• all applications using the auth module should be in the same domain if we want single sign on stuff to work (and cookie would be set under shared domain name). Or we'd have to write a front-end for the auth module and figure out how the cookies would work.

[hackartisan]

Gabe and I created a project at https://github.com/hackmastera/auther https://github.com/mariposacoop/auther and wrote up an API specification there.

[hackartisan]

Questions for future discussion:

• Should the module have a single API key or a different key for each application tht uses it?
• Should the module set 'good password' restrictions or should that be managed by the application?

[gsf]

Let's keep https://github.com/ncb000gt/node.bcrypt.js/ in mind.

[gsf]

Regarding the API specification, we may also want to allow a POST of username, password, timestamp to check for auth, since that's a lot easier to do with an old-fashioned HTML form.

Oh, but now I remember all communication will be server-side anyway. Please disregard. :)

[gsf]

For posterity, I'm putting in here why we decided against http://slide.blorkmark.com/. Because the signature from the client is a hash of the password and the current time, the only way to create the same hash on the server side would be to store the passwords in plain text. So that's not going to work.

[krubokrubo]

Paul's general summary, January 2013

After missing the meeting in June 2012, I kept feeling lost about why we were writing "auther" and "autheremin". What is it useful for? How will it be implemented for end users? Will it be secure---especially considering how the websites above (on coopter/issues/1) have demonstrated weaknesses in every existing authentication scheme? Why are we rolling our own authentication instead of using OpenID or something?

Here is my general understanding after talking this through with the above websites and with Gabe and Anna for the third time. If you have similar questions, this general summary may help.

To begin, remember (or read links above) that all existing authentication systems use the same paradigm: enter your password onto a website. This paradigm has some fundamental weaknesses---users choose weak passwords; users reuse passwords among multiple sites; since the password and/or some other token are passed around through the system, nearly any kind of security compromise of the site can compromise the authentication in some way. If we had a better paradigm, that would be great; given that we don't, all we can do is limit our exposure to possible compromises.

However, this situation is not too bad for Mariposa Co-op, because the value of compromising our site is also limited. Maybe someone could ruin our data; we have back-ups. Maybe someone could deface the site and siphon off our users' passwords or credit card numbers as they are entered. A compromise would be bad, of course, but nowhere near as damaging as for many sites. "We don't have to outrun the bear, we just have to outrun the other guy."

So all that we need is a simple module that can handle authentication for our other present and future modules by storing and testing passwords. We don’t need something complicated like OpenID. It should be similar to how Django already does MESS authentication, except better:

1. It can be used by other modules that aren't written in Django
2. It uses bcrypt which reduces the risk that salted hash passwords, if stolen by an attacker, might be quickly brute-forced
3. It's really simple and therefore it's easy to audit.
   We will accomplish this by implementing auther+autheremin.

Autheremin is the database connection, responsible for storing the passwords and checking them. Auther is the API, responsible for handling requests from other modules. To start with, we will migrate our existing Django app to handle authentication through Auther. That’s today’s planning goal (January 13, 2013). Then as we build more modules, they could also handle authentication through Auther. Eventually, we may move to a model where everything goes through Coopter, and Auther would be one of the modules it connects together, communicating via Roundabout.