Re: Updating fb password storage - Re: [Firebird-devel] crypt plugins

[Mark O'D. <mar...@fi...>]

Hi Alex

Alex Peshkov wrote:
> Dmitry Yemanov wrote:
> 
>> "Mark O'Donohue" <mar...@fi...> wrote:
>> 
>>> 
>>> 1) old client can connect to new servers, 2) new clients still 
>>> talk to old servers.
>>> 
> 
> Yes - except gsec. It uses new spb parameter to specify security 
> database to work with.
> 

I assume gsec not being transportable, is not really a problem, what
about other 3rd party tools?


>>> 3) and even if really needed old security.fdb files could work 
>>> with new servers.
>>> 
> 
> After fix of updatable view in cmp.cpp - yes. I revert back to update
>  of view USERS instead of underlying table in security.epp, and this 
> will work. But it's better to apply script I plan to write to update 
> security database.
> 

I think it's acceptable that only the "new" security.fdb works post this
change, as long as there is an upgrade path, and a clear error when
someone trys it.

I like your idea of an upgrade script to apply to old security.fdb files.

> Looking at the number of mentioned in this thread hashing methods I 
> still think that plugins will be useful.

I suppose Im arguing to upgrade the password hash algorithm which I see 
as highly desirable for fb2.

A plugin architecture seems a larger change, desirable but needing a bit 
  of time to let the design settle and time to implement it.

But I think I can best comment if I can have a look at your plugin code. 
  Do you mind sending me a patch or posting it somewhere.

But, plugin asside, that shouldn't be an impediment to us upgrading the 
hash algorithm for fb2 even if plugin PAM modules make it into fb2 as well.


> Moreover, to be secure we must  be able to turn off DES hashes when 
> needed - for example, in default install. Appears configuration
> parameter will be required for it anyway. Therefore, why not use it 
> at that same time for selecting plugin?

If internally (and in gsec) SHA1/MD5 are used in preference and tried 
first, DES doesn't really need to be turned off.

I really think we want to avoid giving a user a choice about something 
they mostly won't understand. Lets just design the new hash as safe, and 
make it a replacement.

However, a warning script to show users still using the DES MAC for 
passwords would be helpful.


But I'll look forward to seeing the patch.


Cheers

Mark