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

[Alex P. <pe...@in...>]

Mark O'Donohue wrote:

>
> 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?

Tools, based upon service manager, work OK. isc_*_user() functions need 
some more testing, but I think that even if some problems remain, they 
may be easily fixed.

>> 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.
>
Let's distinguish between AUTH plugins, which implementation is really 
none-trivial, and CRYPT plugins, which are as simple as you can't even 
imagine. The main problem was how to remove hash calculation from 
client, but I think we all agree it's anyway required step.

> 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.

I'm afraid AUTH plugins are not real for 2.0. At least we must support 
passing of non-ENC_crypt()ed passwords from client to server - I'm 
afraid PAM will not recognize our crypt hash as password :-).

>
>
>> 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.
>
If we give users default install ONLY with new hashes, they will start 
to make replacements only when need to upgrade old installation. 
Upgrading, they will be not able to login, and (hopefully), will have to 
read documentation. If they don't revert bach to safe hashes only - what 
can we do? There many other ways to help hackers attack one's system - 
my friend was very surprised when got a $700/3days bill for internet 
after setting completely opened proxy on his w2k gateway. And when I 
asked him, has not he forgotten to setup terminal services on that box - 
answer was YES :-)

> However, a warning script to show users still using the DES MAC for 
> passwords would be helpful.
>
Luckily, they differ in length. Therefore this script is possible.

>
> But I'll look forward to seeing the patch.
>
Please download from http://www.insi.yaroslavl.ru/fb/sec.rar (257K).

Alex.