Web Authentication - Revision history

Cadillac at 18:13, 24 August 2021

2021-08-24T18:13:23Z

← Older revision		Revision as of 14:13, 24 August 2021
Line 36:		Line 36:

	{{Sections}}		{{Sections}}

			[[Category:Development]]

Epsy at 21:52, 30 August 2008

2008-08-30T21:52:08Z

← Older revision		Revision as of 17:52, 30 August 2008
Line 27:		Line 27:
	* '''+''' nothing special is required on the client, except an HTTP-compatible client.		* '''+''' 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		* '''-''' 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===		===The gateway===

Epsy: /* The Unholy Trinity */ changed webform handling

2008-05-22T18:45:20Z

The Unholy Trinity: changed webform handling

← Older revision		Revision as of 14:45, 22 May 2008
Line 17:		Line 17:
	===The Unholy Trinity===		===The Unholy Trinity===
	# The user writes his authority name in a form on the site he wants to login to, and submits it		# The user writes his authority name in a form on the site he wants to login to, and submits it
	# The site contacts the authority, checking if it can support the ''webform'' method, then to get that method's PARAMS: ~~the webform's URL and~~ 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).		# 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).
	# The site redirects the user to ~~the~~ webform ~~the authority~~ is proposing with the first key -hashed- as GET parameter		# The site redirects the user to authority/armaauth/0.1/webform is proposing with the first key -hashed- as GET parameter
	# 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 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.		# 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.
Line 27:		Line 27:
	* '''+''' nothing special is required on the client, except an HTTP-compatible client.		* '''+''' 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		* '''-''' 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

	===The gateway===		===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.		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.

Epsy: Reworked unholy trinity method

2008-05-20T19:44:45Z

Reworked unholy trinity method

← Older revision		Revision as of 15:44, 20 May 2008
Line 17:		Line 17:
	===The Unholy Trinity===		===The Unholy Trinity===
	# The user writes his authority name in a form on the site he wants to login to, and submits it		# The user writes his authority name in a form on the site he wants to login to, and submits it
	# The site contacts the authority, checking if it can support the ''webform'' method		# The site contacts the authority, checking if it can support the ''webform'' method, then to get that method's PARAMS: the webform's URL and 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).
	~~# The site sends~~ a ~~randomly-generated~~ key to the authority, and redirects the user to the webform the authority is proposing		# The site redirects the user to the webform the authority is proposing with the first key -hashed- as GET parameter
	# 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 via~~ a ~~GET parameter~~.		# 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.
			# The site now has both keys, hashes them together, and queries a CHECK to the authority :) The authority deletes the second key.
			# 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.		* '''-''' Goes in the opposite direction as the discussed scheme.

Epsy at 12:49, 17 May 2008

2008-05-17T12:49:55Z

← Older revision		Revision as of 08:49, 17 May 2008
Line 27:		Line 27:
	===The gateway===		===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.		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.
	* '''+''' ~~Respects~~ the scheme.		* '''+''' Somewhat respects the scheme.
	* '''-''' Centralized. Poses the problem of reliability and choice of the gateway machine, not ~~to say~~ if ~~a badmin~~ takes control over it..		* '''-''' 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.		* '''+''' nothing special is required on the client, except an HTTP-compatible client.

	{{Sections}}		{{Sections}}

Epsy: appended wrtl's suggestion

2008-05-01T20:29:31Z

appended wrtl's suggestion

← Older revision		Revision as of 16:29, 1 May 2008
Line 10:		Line 10:

	==Ways to go==		==Ways to go==
	~~Currently, I've thought of two ''big'' ways to go:~~

	===Respecting [[Hash Authentication Design]]===		===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.		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.
Line 27:		Line 25:
	* '''+''' nothing special is required on the client, except an HTTP-compatible client.		* '''+''' 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		* '''-''' 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
			===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.
			* '''+''' Respects the scheme.
			* '''-''' Centralized. Poses the problem of reliability and choice of the gateway machine, not to say if a badmin takes control over it..
			* '''+''' nothing special is required on the client, except an HTTP-compatible client.

	{{Sections}}		{{Sections}}

Epsy at 19:52, 22 April 2008

2008-04-22T19:52:00Z

← Older revision		Revision as of 15:52, 22 April 2008
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.

Epsy: first commit

2008-04-22T19:41:45Z

first commit

New page

{{Sections}}

{{Blueprint|web-auth}}

==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===
# The user writes his authority name in a form on the site he wants to login to, and submits it
# The site contacts the authority, checking if it can support the ''webform'' method
# 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
# If the user logins correctly, the authority redirects the user to the original site, also sending the key the site gave it.

* '''-''' 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}}