Re: [Firebird-devel] crypt plugins

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

Alex Peshkov wrote:

>>
>> The point, however, is that the strength of security is the weakest 
>> link, and the hash algorithm is far, far from the weakest link.  It 
>> is rather pointless to worry about the relative merits of SHA versus 
>> MD5 when we're sending passwords in the clear.  Any password sniffer 
>> installed on any lan through which IP traffic passes can pick up the 
>> passwords, so why worry about the hash?
>
>
> The reason is simple. It's easy to protect your network connection 
> from sniffers using any tool you like. But currently it's impossible 
> to protect from 'select user_name, password from users;', no 3-rd 
> party software will help you. Any user can read hashes of all others. 
> We can solve this problem only inside firebird, for example, making 
> hashes harder to brutforce.

Ah, clearly you have never run a network of Linux servers.  The life 
expectancy of an out-of-the-box Linux from a disto is about 72 hours.  
However, even without hackers, any PC user can put his ethernet board 
into promiscuous mode and get all traffic.  And if you leave your LAN, 
every node on any IP routing can read your traffic.  Do you really want 
to hand them your passwords?

If you don't believe in the strength of encryption, however, nothing 
works.  For security design purposes, secure hash is presumed secure.  
In practice and known theory, SHA is secure.  Loss of password over the 
wire is 10**10 more important than worrying that someone will break a 
secure hash.

>
>>
>> The reason that a security architecture is essential is to determine 
>> the relative strengths of the links and shore up the weaker.  Sure, 
>> the existing cypt is a farce and should be replaced with SHA, but the 
>> rest of your proposal adds nothing to security and gets in the way of 
>> doing it right.
>>
> Without the rest of my proposals new hashes don't work, I mean don't 
> work reliably. Assume sysdba attaching to server with gsec version 
> 1.5. He successfully changes sysdba's password (yes, he is wrong, but 
> he is even not warned about!), but this is not SHA hash, this is 
> existing crypt hash. The only known to me way to save such database is 
> to copy it to the server with working firebird and use new gsec. 
> Almost all the rest of my proposals is to exclude such situation. What 
> about replacing crypt with HSA - it is certainly possible, but plugins 
> desision seems better. 

Why not just encode all new passwords with SHA (no choice) and check 
first for SHA then crypt.  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.

> Why force people using one and only one kind of hash? Experts now say 
> that SHA is safe, but when current crypt was used it also seemed to be 
> OK. 

Crypt is what all Unix systems used at the time.  Not much point in 
being more secure than the platform you run on.  It was a bad choice, 
but better than rolling their own.  In any case, they (the Borland guys) 
didn't think about it very much.

>>>> I asked before that a security architect be developed and discussed 
>>>> before anything was implemented.  Without a security architecture, 
>>>> how do we know how a smattering of features interplays with other 
>>>> work under development?  For example, Interbase and Firebird 
>>>> through 2.0 use an architecturally unsupportable hack that breaks 
>>>> the layering to connect to the security database.  It can't be 
>>>> implemented in Vulcan.  You're adding special semantics for the 
>>>> security database.  How does it know that it's a security database?  
>>>
>>>
>>>
>>>
>>> It asks class SecurityDatabase about security db-name, and compares 
>>> with one to be attached.
>>
>>
>>
>> Vulcan supports any number of security databases.  Your scheme is 
>> useless in version 3.  But since there is no reliable way to compare 
>> two Windows filenames (which is the source of endless database 
>> corruptions), your scheme doesn't even work in version 2.
>
>
> 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.

> May be there are special tricks to break this method, but being used 
> they will lead to corruption of security.fdb, as you mentioned 
> already, and I changed nothing here. I hope that this scheme will not 
> be needed in v.3 with new security architecture, but in version 2 it 
> is needed for one simple reason - help people avoid attaching to 
> security database using old versions of gsec, which used to build 
> hashes on the client. If sysdba wants to break security database (or 
> user wants to attach to it and write bad hash for hymself), certainly 
> he can do it, but this is not a trivial task, and he will not do it 
> accidentially, as it was really easy without this change.

Again, it doesn't work in V2 and it's a non-starter in V3. 

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