Web Authentication

From Armagetron
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Sections: Installing the Game | Playing the Game | Competition Hub | Server Administration | Extending Armagetron Advanced | Development Docs


This wiki page has an associated Blueprint on launchpad.

Goals

  • Being able to authenticate on "any" website with a single Global ID, as if you were already registered there
  • ..meaning your profile info has to be passed somewhere, so we'd need some little profile protocol
  • Make it easy for sites to implement Global ID logins
  • Not going too far..do we want this to become something like Gravatar, or anything of such sort? or not?

Ways to go

Respecting Hash Authentication Design

There would be a (client-side) javascript, scrambling the password, and it would go trough our server we want to login to, and so forth, as like described on the page linked above.

  • + Respects the scheme.
  • - Uses javascript, excludes users who turned off javascript, and anyway we want the least possible javascript, don't we?
  • - Phishing is easier, just remove the javascript, and we can't tell our users to search source to see if their password is going to be scrambled or not.

The Unholy Trinity

  1. The user writes his authority name in a form on the site he wants to login to, and submits it
  2. The site contacts the authority, checking if it can support the webform method, then to get that method's PARAMS: a key. This key will be stored by the server and the authority(at the authority side it's better to store it both hashed and clear - along with the site contacting).
  3. The site redirects the user to authority/armaauth/0.1/webform is proposing with the first key -hashed- as GET parameter
  4. The authority shows a form, the user fills in his login details
  5. If the user logins correctly, the authority redirects the user to the original site, also sending a second key via a GET parameter. The time the key is sent is recorded along with the site which has been contacting the authority.
  6. The site now has both keys, hashes them together, and queries a CHECK to the authority :) The authority deletes the second key.
  7. The site may now ask for the user's profile, sending the user's username and the first key we had earlier. The authority may delete this key too once that's done or when 5 minutes pass, whichever comes first.
  • - Goes in the opposite direction as the discussed scheme.
  • + nothing special is required on the client, except an HTTP-compatible client.
  • - Phishing is still possible, but minimized: a site could send the user to an innocent-looking site which prompts it to login, sends the username/password verbatim to the real authority, and gets if the username/password was right. Against that we can simply tell our users to look at their address bar, some red banner at each authority might do the trick
  • + Authentifies the website, useful especially for sending critical information such as e-mail etc

The gateway

We respect the spec, but instead of having the client(the browser) run some client side code we send it to some gateway which does the computing that should be done by the client.

  • + Somewhat respects the scheme.
  • - Centralized. Poses the problem of reliability and choice of the gateway machine, not even mentioning what would happen if an admin takes control over it..
  • + nothing special is required on the client, except an HTTP-compatible client.

Sections: Installing the Game | Playing the Game | Competition Hub | Server Administration | Extending Armagetron Advanced | Development Docs