From 2a64eea0f51a431abe9c0a7c73a61f3177977790 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 14 May 2015 11:02:57 -0400 Subject: comments --- .../separate_authentication_from_authorization.mdwn | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn index de7c5b763..389f014c9 100644 --- a/doc/todo/separate_authentication_from_authorization.mdwn +++ b/doc/todo/separate_authentication_from_authorization.mdwn @@ -35,6 +35,13 @@ Here is a sketch of a different account model that would address that: users with / in their names, which would make their user-page into a subpage? + > I have fixed passwordauth to not let urls be registered. It seems this + > was not quite a security hole; it didn't let registering a username that + > already existed, so if an openid was an admin, as long as the user logged + > in using that openid, someone else couldn't come along and passwordauth + > collide with it. (Might be exploitable if you could guess an openid that + > was going to be added as an admin later though.) --[[Joey]] + * If passwordauth is enabled, accounts may have a password. Users can authenticate to an account that has a password by entering that password. The username is always the account name (because there's little reason @@ -95,12 +102,6 @@ Thoughts? > > Also, when you talk about "separating authentication from authorization", i immediately thought of [[todo/ACL/]] and [[todo/Zoned_ikiwiki/]], so i thought i could mention those... having stability in the usernames would help in the design of those... --[[anarcat]] -> I'm not against this, but I don't anticipate having resources to do any -> work on it either. --[[Joey]] - -> I have fixed passwordauth to not let urls be registered. It seems this -> was not quite a security hole; it didn't let registering a name that -> already existed, so if an openid was an admin, as long as the user logged -> in using that openid, someone else couldn't come along and passwordauth -> collide with it. (Might be exploitable if you could guess an openid that -> was going to be added as an admin though.) --[[Joey]] +> I'm not opposed to this, but I don't anticipate having resources to do any +> work on it either. (I do hope to obscure email addresses from git +> commits.) --[[Joey]] -- cgit v1.2.3