Difference between revisions of "Talk:Key Based Authentication"
From Armagetron
m |
|||
| Line 4: | Line 4: | ||
[[User:Meriton|Meriton]] 14:24, 6 March 2006 (CST) | [[User:Meriton|Meriton]] 14:24, 6 March 2006 (CST) | ||
| + | |||
| + | That is so that the user only has to remember and take care of his username and password, a public/private key pair is harder to manage. It's required for the Uncle Joe scenario that the key is not managed on the client. The user has the possibility to make his client his authority and generate his key for himself if he wishes, gaining independence from external authorities and additional privacy, but losing Uncle Joe. | ||
| + | |||
| + | [[User:Z-man|Z-Man]] 16:21, 7 March 2006 (CST) | ||
Latest revision as of 18:21, 7 March 2006
Questions:
- Why does the auth server generate the player's private key? That empowers the auth server's admin to impersonate the player. In a standard PK-Architecture, the authority only signs the player's public key.
Meriton 14:24, 6 March 2006 (CST)
That is so that the user only has to remember and take care of his username and password, a public/private key pair is harder to manage. It's required for the Uncle Joe scenario that the key is not managed on the client. The user has the possibility to make his client his authority and generate his key for himself if he wishes, gaining independence from external authorities and additional privacy, but losing Uncle Joe.
Z-Man 16:21, 7 March 2006 (CST)
