[Tickets #2865] Support for switching to a new password scheme

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2865
-----------------------------------------------------------------------
 Ticket             | 2865
 Updated By         | ulrich-horde at topfen.net
 Summary            | Support for switching to a new password scheme
 Queue              | Passwd
 Version            | HEAD
 State              | Feedback
 Priority           | 2. Medium
 Type               | Enhancement
 Owners             | 
-----------------------------------------------------------------------


ulrich-horde at topfen.net (2005-10-31 15:01) wrote:

> I'm trying to wrap my head around whether or not this is a bad idea 
> security-wise - it seems dodgy to me.

As you may have guessed, I don't really see a security problem with this
patch -- it's just a way of finding out what scheme a password is stored
in, and then comparing the plaintext accordingly. Here's two points that
your response made me think about and my reasons for why they're not
security problems.
In case that an unknown (or no) encryption scheme is found,
Auth::getCryptedPassword() assumes hex-encoded MD5 as default. In the
worst case, we may end up comparing two passwords hashed with different
functions. As finding collisions (i.e. two different inputs that produce
the same output) is assumed to be infeasible for any (good) hash function,
and, more generally, finding the pre-image of a hash function (i.e.
finding the input given only the output) is also thought to be difficult,
finding any input value for $plaintext for which the MD5-hex hash is the
same as $encrypted (hashed and encoded with a different scheme) is
difficult as well.
The regular expression for finding the scheme is also very simple -- it
looks for anything within curly brackets and uses it as the scheme name.
Doing Bad Things(tm) with that is impossible because (a) $encrypted is
from a trusted source and (b) if the scheme can't be found, the above
kicks in.

Maybe this behaviour could be turned on by a configuration option, with
the default set to disabled.

> Also, your patch doesn't take into account _not_ finding the encryption
> type and never sets $encryption for that case.

Yes. Sorry, that must have slipped my mind, but is trivial to fix. Tell me
if you want me to do it.