Difference between revisions of "Web Authentication"

From Armagetron
(first commit)
 
Line 22: Line 22:
 
# The site sends a randomly-generated key to the authority, and redirects the user to the webform the authority is proposing
 
# The site sends a randomly-generated key to the authority, and redirects the user to the webform the authority is proposing
 
# The authority shows a form, the user fills in his login details
 
# The authority shows a form, the user fills in his login details
# If the user logins correctly, the authority redirects the user to the original site, also sending the key the site gave it.
+
# If the user logins correctly, the authority redirects the user to the original site, also sending the key the site gave it via a GET parameter.
  
 
* '''-''' Goes in the opposite direction as the discussed scheme.
 
* '''-''' Goes in the opposite direction as the discussed scheme.

Revision as of 15:52, 22 April 2008


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

Currently, I've thought of two big 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
  3. The site sends a randomly-generated key to the authority, and redirects the user to the webform the authority is proposing
  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 the key the site gave it via a GET parameter.
  • - 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

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