Authentication integration: Difference between revisions

From OpenHatch wiki
Content added Content deleted
imported>Paulproteus
imported>Paulproteus
No edit summary
Line 3: Line 3:
The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki and we are [[choosing a forum]]. I'd like logins to be integrated.
The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki and we are [[choosing a forum]]. I'd like logins to be integrated.


== Strategy ==
== Overview ==


Django code creates domain cookies within openhatch.org that contain the user's username and email address. The application (like the wiki) can read that information and verify it using HMAC-SHA1.
Only applications in *.openhatch.org can receive user data. HMAC-SHA1 is used to verify the authenticity of the data that is passed through. Th


== Details ==
When (e.g.) the wiki wants to get the OpenHatch username and email address corresponding to the current session, it


=== Application: redirect ===
=== Application: redirect ===
Line 34: Line 34:
The application should make its own "logged in" status expire at the end of the session.
The application should make its own "logged in" status expire at the end of the session.


== Known issues ==

There are some problems with this setup. Some security issues:

* Email addresses and usernames travel along the network unencrypted. (In practice, this is no worse than the status quo, since session IDs already do that.)
* Not all applications treat usernames as case-sensitive. This might allow an attacker to create a new username that is treated as equivalent to a different user, effectively stealing an account.
** We can fix this by constraining usernames on the Django side to be case-insensitively unique.
*** Right now, Django usernames [http://code.djangoproject.com/ticket/2273 seem to be case sensitive].

Some usability issues:

* The first time the user goes to the forum, the browser will redirect a few times. That'll be weird.

Missing features:

* If an account gets deleted within the OpenHatch Django app, we don't have a way to ask downstream applications to delete their account of the same name.


[[Category:Hacking_OpenHatch]]
[[Category:Hacking_OpenHatch]]

Revision as of 21:58, 4 September 2010

Purpose

The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki and we are choosing a forum. I'd like logins to be integrated.

Overview

Django code creates domain cookies within openhatch.org that contain the user's username and email address. The application (like the wiki) can read that information and verify it using HMAC-SHA1.

Details

Application: redirect

If the wiki detects an OpenHatch session cookie, it redirects the user to http://openhatch.org/+create_user_data_cookie?redirect_to=http://openhatch.org/wiki/handle_login.php

Django code: create_user_data cookies

The OpenHatch site creates some cookies. All cookies contain text. We encode it as UTF-8 and then wrap that in base64.

The "message" that we HMAC is the final, base64-encoded data.

  • user_data__email_address: This contains the user's email address.
  • user_data__email_address__hmac: This contains a HMAC-SHA1 to verify the authenticity of the email address.
  • user_data__username: This contains the user's username.
  • user_data__username__hmac: This contains a HMAC-SHA1 of the username.

Application: Read cookie data, then delete cookies

Now it's time for the application (e.g., the wiki) to read the user data and log the user in.

It should delete the user_data__* cookies that it read, to avoid keeping clutter in the user's browser.

That's up to the application. It MUST verify the user_data__* using HMAC-SHA1 before trusting it, as users can tamper with this data.

The application should make its own "logged in" status expire at the end of the session.

Known issues

There are some problems with this setup. Some security issues:

  • Email addresses and usernames travel along the network unencrypted. (In practice, this is no worse than the status quo, since session IDs already do that.)
  • Not all applications treat usernames as case-sensitive. This might allow an attacker to create a new username that is treated as equivalent to a different user, effectively stealing an account.
    • We can fix this by constraining usernames on the Django side to be case-insensitively unique.

Some usability issues:

  • The first time the user goes to the forum, the browser will redirect a few times. That'll be weird.

Missing features:

  • If an account gets deleted within the OpenHatch Django app, we don't have a way to ask downstream applications to delete their account of the same name.