Item4824: Security bug: TWiki's user management code needs rework again

I know it has been reworked for 4.2, or better for every release since 4.0, but: The user management, in particular, TWiki::Users.pm needs to be reworked.

1. The spec is ambiguous. A canonical user id pos_64MY_46DOMAIN could either be a kerberos principal pos@MY.DOMAIN or a user 64_MY_46DOMAIN in some strange user mapping pos.
2. The spec is apparently unclear. When tracing through a failed registration for Item4771, counting revealed:
   1. 49 invocations of forceCUID with the already escaped user id pos_64MY_46DOMAIN. Maybe it needs to be "safe" to call forceCUID with an already cUID-safe value, but 49 times is way to often. It must be well-defined from where in the process a request has a valid cUID. Note: This is a count for a not yet registered user whose name does not occur in any topics nor password files.
   2. 39 invocations of handlesUser, 37 calls to _getMapping, 40 calls to fetchPass, all for the same user id.
3. TWikiUserMapping::userExists is broken because it always calls the current user existing (regardless of whether she is registered). It is broken again if PasswordManager = none because it consults fetchPass instead of TWikiUsers to find out whether a user exists.

No wonder that, after so many calls, TWiki itself has convinced itself that it knows the user and he must not register again.

I call this an "Enhancement", hoping that the user management can be "fixed" to make 4.2 somehow workable.

-- TWiki:Main/HaraldJoerg - 14 Oct 2007

Hararld, damn right. Good feedback. I raise this item to urgent so that it gets more attention. I consider the current implementation of forceCUID a security problem as different logins are forced on the same CUID. So by registering a well chosen login name you can break into someone else's account and get his/her authorizations.

A public TWiki using login names is only secure if it does uses characthers A-Z, a-z, 0-9 and _ in login names. A TWikiAdmin with login tom.t will be in danger to be hiajcked by any new user registering a login name tom_46t. Both these login names are mapped to the same cUID by forceCUID().

--TWiki:Main/MichaelDaum - 12 Jun 2008

I'm not at all sure that the code in 4.2.0 actually has a security problem - but I'm happy that Micha seems to have time to look into it.

-- TWiki:Main.SvenDowideit - 12 Jun 2008

The user code you wrote, Sven, is inefficient and broken by design, which translate to a security problem. forceCUID maps two namespaces on each other: (1) login names and (2) CUIDs. However the second namespace is smaller than the first. Please, try to convince me that I am wrong and that this is not a security problem.

-- TWiki:Main.MichaelDaum - 19 Jun 2008

I'm not trying to convince you one way or the other. I'm simply looking forward to your unit tests and fixes.

-- TWiki:Main.SvenDowideit - 19 Jun 2008

This is too much of a burden. Could you please do this? Last but not least, you are the original author of all this.

-- TWiki:Main.MichaelDaum - 04 Jul 2008