Re: [VuFind-Tech] Hashing passwords (VUFIND-340)

[Demian K. <dem...@vi...>]

I'm happy to move forward with configuration option #3, for the moment at least.  I'll bring this up on the next developers call to see if anyone has opinions they haven't expressed on the mailing list yet.

Regarding cryptography, perhaps the most flexible solution is to abstract encryption-related calls through a custom class that uses mcrypt by default.  Then it should be easy to patch in a pure-PHP crypto library with minimum disruption to the other code if necessary, but we don't actually have to ship crypto libraries with VuFind.  Of course, now that I think about it, VuFind has been shipping with RC4 libraries since before I joined the project, so maybe there's nothing new going on here.

- Demian

> -----Original Message-----
> From: Mark Triggs [mailto:ma...@di...]
> Sent: Thursday, March 29, 2012 3:08 AM
> To: Demian Katz
> Cc: vuf...@li...
> Subject: Re: [VuFind-Tech] Hashing passwords (VUFIND-340)
> 
> In the hope that the right answer will jump out, the options so far and
> their corresponding downsides (since the downsides seem to define them
> :)
> 
>   1. Passwords scheme not explicitly set--code uses heuristics to decide
>     whether to create hashed passwords:
> 
>     - Not exactly self-evident.
> 
>     - Needs some extra DB lookups when creating accounts to work out
>       which password scheme to use.
> 
>   2. Password scheme explicitly set in config file
> 
>     - Risks having the config file say one thing and the database
>       another.  People might enable password hashing but leave plaintext
>       passwords in their DBs, or attempt to switch hashed passwords off
>       without having plaintext passwords stored for their users.
> 
>     - Could try validating the config using DB lookups like the previous
>       option, but these would need to happen for every request instead
>       of just at account creation(?)
> 
>   3. "Capabilities" flag added to the database by the migration
> 
>     - Requires an extra database table.
> 
>   4. "Capabilities' flag added to the config file by the migration
> 
>     - Needs to be obvious to the user that it's not intended to be
>       edited by hand.
> 
> 
> I think my preference is for #3 since it doesn't require any special
> care from the user (no "Don't edit this!" or "If you edit this, make
> sure you ..."), and we could make it use sensible defaults like enabling
> hashed passwords for new installations but leaving it off for people
> upgrading (until they run the migration).  Ultimately I'm happy to
> implement whatever you think is best, though.  Your judgement will be
> better than mine.
> 
> I'm happy to switch to using the PHP mcrypt extension for this stuff
> (http://php.net/manual/en/book.mcrypt.php) if shipping with crypto code
> is a worry.  I have no idea either whether it's likely to cause
> problems, but it's not hard to switch (and I can use it for the
> subsequent cat_user/cat_password encryption too).  I'll go ahead and do
> that.
> 
> Thanks,
> 
> Mark
> 
> 
> Demian Katz <dem...@vi...> writes:
> 
> > Regarding the mode detection, a couple of thoughts:
> >
> > 1.) The config setting might still be workable if carefully named and
> > well-commented...  and you might be able to build in at least some
> > limited level of validation (i.e. if the setting is "encrypted" but an
> > account contains a clear-text password, throw a fatal exception;
> > presumably the user will test the code after changing the setting and
> > will see the error).  Another option would be to have the migration
> > write an obviously non-human-readable value into the config file.
> > However, I definitely see your point that none of these options are
> > very pretty.
> >
> > 2.) The idea of a capabilities table could work too.  I'm not
> > incredibly eager to add lots of extra tables to the VuFind database,
> > but this might be justified.  It could also be useful for other
> > purposes -- i.e. migration and install scripts could write version
> > numbers into it so we know the current VuFind version.
> >
> > Also, another thought on this -- migrations are fine, but what about
> > first-time installations?  I suppose whatever approach we take, VuFind
> > can populate a default value upon first run if necessary...  but I'm
> > beginning to think that a config setting with an appropriate
> > disclaimer may be the best approach after all; why over-engineer it?
> >
> > Regarding the encryption, I'm not sure exactly how this works (and
> > should do some research before committing anything), but aren't there
> > legal restrictions in some regions on distributing software with
> > cryptographic components?  I wonder if bundling a cryptography library
> > might cause distribution problems for VuFind.  Perhaps it is safer (if
> > less convenient) to require an extension to be compiled into PHP and
> > to fail in the migration if the prerequisites are not available.  It's
> > possible I'm being overly paranoid, and I certainly don't believe that
> > distributing an existing cryptography library with VuFind actually
> > poses any sort of new threat to anyone, but I try to be cautious when
> > it comes to legal matters that I don't really understand.
> 
> --
> Mark Triggs
> <ma...@di...>