[Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hi there,
> 
> Uli Fouquet wrote:
>> I'd be glad to provide a fix for this, but I am undecided how we could
>> support administrators best to upgrade their password bases.
> 
> I'm speaking here mostly from a position of ignorance of these affairs, 
> but is it possible to upgrade the current passwords to a more secure 
> version without knowing those passwords?

If that is possible, then we have a worse problem on hand. :)  Passwords
aren't meant to be stored in a reversible / recoverable manner.

>> Currently, three (not mutual exclusive) approaches come to my mind:
>>
>> 1) the fixed password managers could be registered under different 
>>    names. Support of the old ones could slowly run out and users could
>>    be warned, if they still use the old password managers.
> 
> If we were to fix the old password managers, would the old passwords 
> break? If not, that would at least provide better security for newly 
> stored passwords right away without having to change applications.

In a PAS environment, the way to do this is to add a new authentication
plugin, which imposes the new scheme, and be williing to fall back to
the old one.  You also need to replace the plugin which is responsible
for the "update credentials" bit, so that when the user updates her
password, it gets stored in the new way.  Finally, the admin might want
to ask all users to change passwords in order to clear out the weaker set.

There isn't going to be any easy way to automate this kind of upgrade.

>>    The old password managers then could be used as a fallback. This 
>>    would weaken security (as two different hashes would allow one to 
>>    authenticate with the same password), but not very much (you get a 
>>    chance of 2:8**20 instead of 1:8**20 in worst case).
> 
> If it's not possible to update the existing password managers to the new 
> behavior a new name + fallback sounds like the best way to go.
> 
>>    Paranoid folks should be able to disable the fallback and expect 
>>    complaints from their users. Default policy might be to disable
>>    fallback.
> 
> Possibly simply register 2 new names then, one without fallback and one 
> with.
> 
>> 2) A commandline tool should be available, that can at least get old 
>>    (encrypted) passwords and tell how they look hashed proper. 
>>    Administrators had to take care for storing them in site.zcml, their 
>>    LDAP or wherever they store passwords.
> 
> Why a commandline tool? Wouldn't it be better to just have an API to 
> help upgrade passwords?
> 
>> 3) A commandline tool could also update existing ZCML files. This might 
>>    fix the problems for most users.
> 
> I don't think that would fix it for most users. In fact I think those 
> few hashes that are stored in ZCML are not a great security risk; if 
> malicious people can read those the risk to the application is far 
> greater already. The risk is bigger for larger password databases that 
> fall into the wrong hands, as far as I understand it.

An attacker who can get to your password database is already well past
our "ordinary" security measures:  given filesystem access, he can
steal, or even modify, any of the data those passwords are aimed at
protecting.  Because many users reuse passwords across systems, there is
a second-order effect:  being able to crack the Phred's password on one
system might give access to Phred's accounts on *other* systems.  Making
the hash stronger really only defends against this second-order attack.

>> There might be smarter approaches. Any hints are very welcome.
> 
> The most important part I think is to document well what people should 
> be doing. I.e. use the new password managers (or tell them to upgrade 
> and their old ones will be fine), and how they should go about upgrading 
> existing passwords.
> 
> I think we should ask people to write their own upgrade code as we do 
> not know where these passwords are stored. I'm storing them in a 
> relational database in some cases, for instance. We could provide 
> upgrade code for some common scenarios, but I'd be fine if we had a good 
> document with instructions instead.

Agreed:  no general solution seems possible.  I wouldn't suggest
anything more than a code snippet:  anything shipped as actual software
is likely to be an "attractive nuisance."


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJdLje+gerLs4ltQ4RAhEvAJ4gmbqOegwWs/nnshG2ZdXI07AzwQCfQaD7
cSN7/TxRxXTjuYwiuUROaxE=
=CpNh
-----END PGP SIGNATURE-----