Hash Based Authentication - Revision history

Cadillac at 16:22, 23 August 2021

2021-08-23T16:22:33Z

← Older revision		Revision as of 12:22, 23 August 2021
Line 99:		Line 99:

	With the collected list, the server can assign each user account the human readable identifier <user name>@<authentication server nickname>.		With the collected list, the server can assign each user account the human readable identifier <user name>@<authentication server nickname>.

			[[Category:Development]]

2006-03-06T22:43:40Z

Name Resolution

@@ Line 77: / Line 77: @@
 === leaking authorities ===
 Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.
 == Name Resolution ==

2006-03-06T22:01:51Z

← Older revision		Revision as of 18:01, 6 March 2006
Line 77:		Line 77:
	=== leaking authorities ===		=== leaking authorities ===
	Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.		Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.

			== Name Resolution ==

2006-03-06T21:59:53Z

Faking the Authentication Server

← Older revision		Revision as of 17:59, 6 March 2006
Line 68:		Line 68:
	=== Faking the Authentication Server ===		=== Faking the Authentication Server ===

	If someone can forge the authentication server's response to the game server, he obviously can get free entry into the game server as anyone he wants. Real cryptography could help here (we're not bound to the ingame network protocol here and could use ssl), but at least, the game server's message needs to also contain a randomly chosen token the authentication server's response has to mirror, or else the attacker can try to inject a forged response without being able to read the network traffic.		If someone can forge the authentication server's response to the game server, he obviously can get free entry into the game server as anyone he wants. Countermeasure: Real cryptography could help here (we're not bound to the ingame network protocol here and could use ssl), but at least, the game server's message needs to also contain a randomly chosen token the authentication server's response has to mirror, or else the attacker can try to inject a forged response without being able to read the network traffic.

	=== attacking the auth server ===		=== attacking the auth server ===

2006-03-06T21:59:20Z

attacking the auth server

← Older revision		Revision as of 17:59, 6 March 2006
Line 72:		Line 72:
	=== attacking the auth server ===		=== attacking the auth server ===

	This is an online-protocol, i.e. the ~~authentification~~ server must be online in order to authenticate a player. It is therefore possible to prevent specific players from playing by bringing down their auth server.		This is an online-protocol, i.e. the authentication server must be online in order to authenticate a player. It is therefore possible to prevent specific players from playing by bringing down their auth server.
			Countermeasure: the game server could fetch auth challenges from the auth server for later use and store them locally; short downtimes of the auth server will then only affect players visiting a game server for the first time, when no supply of challenges for them is ready yet.

	=== leaking authorities ===		=== leaking authorities ===
	Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.		Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.

2006-03-06T21:57:06Z

leaking authorities

← Older revision		Revision as of 17:57, 6 March 2006
Line 75:		Line 75:

	=== leaking authorities ===		=== leaking authorities ===
	Read-only access to a record in the authority's database is sufficient to impersonate that player.		Read-only access to a record in the authority's database is sufficient to impersonate that player. Of course, similar things are true for all authentication schemes.

2006-03-06T20:00:48Z

leaking authorities

← Older revision		Revision as of 16:00, 6 March 2006
Line 73:		Line 73:

	This is an online-protocol, i.e. the authentification server must be online in order to authenticate a player. It is therefore possible to prevent specific players from playing by bringing down their auth server.		This is an online-protocol, i.e. the authentification server must be online in order to authenticate a player. It is therefore possible to prevent specific players from playing by bringing down their auth server.

			=== leaking authorities ===
			Read-only access to a record in the authority's database is sufficient to impersonate that player.

2006-03-06T19:54:40Z

mention availability vulnerability

← Older revision		Revision as of 15:54, 6 March 2006
Line 69:		Line 69:

	If someone can forge the authentication server's response to the game server, he obviously can get free entry into the game server as anyone he wants. Real cryptography could help here (we're not bound to the ingame network protocol here and could use ssl), but at least, the game server's message needs to also contain a randomly chosen token the authentication server's response has to mirror, or else the attacker can try to inject a forged response without being able to read the network traffic.		If someone can forge the authentication server's response to the game server, he obviously can get free entry into the game server as anyone he wants. Real cryptography could help here (we're not bound to the ingame network protocol here and could use ssl), but at least, the game server's message needs to also contain a randomly chosen token the authentication server's response has to mirror, or else the attacker can try to inject a forged response without being able to read the network traffic.

			=== attacking the auth server ===

			This is an online-protocol, i.e. the authentification server must be online in order to authenticate a player. It is therefore possible to prevent specific players from playing by bringing down their auth server.

2006-03-06T19:50:24Z

one-wayness of H is not sufficient for security

← Older revision		Revision as of 15:50, 6 March 2006
Line 18:		Line 18:
	* V accepts iff h0=H(d+s)		* V accepts iff h0=H(d+s)

	where ~~H is a one-way function and~~ + denotes string concatenation.		where + denotes string concatenation.

	== On the Client ==		== On the Client ==

2006-03-06T19:27:22Z

clarified purpose of scambled eggs, stated correct requirements on H

← Older revision		Revision as of 15:27, 6 March 2006
Line 11:		Line 11:
	The authentication server holds a database of usernames and hash functions of their passwords.		The authentication server holds a database of usernames and hash functions of their passwords.

	~~Important~~ sub-recipe~~: scrambling~~ eggs. ~~You take~~ a ~~(usually~~ random~~) salt~~ s~~, some data d~~ (the ~~egg~~), and ~~calculate~~ H(s+d), where + ~~here means simple~~ concatenation.		=== Scrambling eggs ===
			An important sub-recipe is the scambling eggs-protocol, which is designed to permit an entity P to prove to an entitiy V that it knows a shared secret d without enabling an eavesdropper C to convince V. It works as follows:

			* V generates a random bitstring s (the salt) and sends it to P
			* P computes h0=H(d+s) and sends it to V
			* V accepts iff h0=H(d+s)

			where H is a one-way function and + denotes string concatenation.

	== On the Client ==		== On the Client ==