Re: [Firebird-devel] crypt plugins

[Jim S. <ja...@ne...>]

Alex Peshkov wrote:

> Jim Starkey wrote:
>
>> Why not just encode all new passwords with SHA (no choice) and check 
>> first for SHA then crypt.  
>
>
> And at any moment have a number of passwords in crypt, not SHA, due to 
> bad client, and without any warnings... I wanted to make default 
> install without attempt to check for crypt hash.

A new install won't have any crypt hashed passwords.  An update will, 
however, but unless you are prepared to brute force crypt for recover 
the original passwords (good luck), the clients will have to recreate 
their passwords anyway, which will be hash by SHA.  I wouldn't bother 
with warnings; the system has worked that way since Interbase version 4, 
and if any case, you really aren't increasing the security of the system.

>> Then no changes are necessary in any tools.  All a DBA has to do to 
>> cut over is redefine all passwords.  It compatible, no worse than 
>> what is there now, and he can do it at his leasure.
>
First, SHA is sufficient.  Second, we don't have a security architecture 
or a serious design for a security plugin, so anything you do now is 
likely going to be deprecated in the next release.  Third, either you 
restrict the user to a small set of builtin alternatives (none of which 
would be better than SHA), you have to go through the fuss and bother of 
designing an API for loadable hash algorithms.  Fourth, the necessary 
changes to the configuration file will be inconsistent with Vulcan 
configuration files (Vulcan supports an object type for security 
plugin).  Fifth, the hash algorithm is a property of one particularly 
security option, so it shouldn't be in the core system.  Sixth, the 
"plugin manager" has been dropped from Vulcan as non-portable and 
replaced with a set of layered classes, so you implementation would be 
throw away.

Bottom line: Because it's a lot of work that introduces more serious 
problems than it solves.  It's short sighted, doesn't address serious 
problem, and isn't part of a coherent security architecture.

>>>
>>> Current isc_expand() seems to give reliable results for existing files.
>>
>> Alex, it doesn't.  It can't detect that a local file with a remote 
>> mount are the same.  That's how databases get trashed.  It's also how 
>> to break your scheme.
>
>
> Ouuh, that's a bug in ISC_expand_filename(). I haven't known about it. 
> Or may be it's a feature to access remote files on local sql server? I 
> see a clear way to fix it, but may be someone use it as a 'feature'?

If you have a solution you will save dozens of users from opening 
database with different path names, getting different lock tables, and 
trashing their databases.  If you've got a fix, the lock manager needs it.

>>> May be - I trusted information reported by someone (Mark ? Sorry, 
>>> don't remember exactly) in fb* lists, that current hashes are not 
>>> enough strong for brutforce. I didn't try myself.
>>
>>
>> This would be big news in the crypto community.  If he can break SHA, 
>> he will be rich and famous.
>>
> No, crypt was mentioned there. It's some misunderstanding, sorry. I 
> meant crypt/DES.
>
Crypt was secure on a PDP-11/40.  Computers have gotten faster since 
then.  DES was down graded from a 64 bit key to a 56 bit key so it could 
be broken.  But please remember, security is only as strong as the 
weakest link, and even DES would be a step up.

If you want to do something useful before we can agree on a security 
architecture, why not implement "create user" in SQL so we can phase out 
gsec altogether?

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376