Re: [Firebird-devel] crypt plugins

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

Jim Starkey wrote:

>
>
> Alex Peshkov wrote:
>
> Wrong on every count.  The SHA hashes are considered by security 
> experts to be secure.  SHA-1 produces a 160 bit hash, which is 
> considered unbreakable.  It can be broken by iterating through every 
> possible password or lists of possible passwords, but reasonable 
> password security can readily defeat that.
>
> 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.

>
> 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.
>
Agreed, letting users change there passwords, stands aside. I was wrong 
mixing two different features together. But do you think it's useless?
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 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.

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

>>
>>
>> Appears with exesting hashes - can. It's possible to brutforce them.
>
>
> You might want to do some homework before you make this statement.

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.

>
>>
>>> Trying to hide the hash is completely pointless.  
>>
>>
>>
>> Please compare /etc/passwd and /etc/master.passwd in FreeBSD. Are you 
>> sure they do pointless things?
>
>
> We're talking about Firebird here.  What FreeBSD may or may not have 
> done has nothing to do with the merits of your proposal.  If you have 
> a security analysis, publish it and we'll consider it.  Otherwise, 
> write one.

Agreed, and this was not my purporse. I wanted to let people, not happy 
with quality of current hashes, use one they like.

>
>>
>>> Hiding it in an ineffective manner is less than pointless.  
>>
>>
>>
>> With some additional work done I can effectively hide them for remote 
>> connections. Is this pointless? If sysadmin wants to hide them 
>> completely, it's enough for him to block local (embedded) connections.
>
>
> Yes, it is pointless.   You can't block embedded access if the file 
> can be read.  All you can do is make it moderately inconvenient.  
> Don't confuse "inconvenient" with "secure".

Agreed once more. I wanted to make it inconvenient to avoid accidential 
misuse with old tools.

>>
>>> Without an end to end analysis, plugging perceived holes is dumb.  
>>> The politcally/correct hack was an example of really stupid design, 
>>> as was the silly idea of "encrypting" passwords on the wire.  
>>> Plugging holes usually means little plugs in big holes that do 
>>> nothing to make the entire system more secure.  At worst, they are 
>>> ineffective hacks that interfere with future robust security.
>>
>>
>>
>> I tried to avoid mentioned problems, but before discussing something 
>> public, it was necessary (for me) to have a working prototype. 
>> Building it helped me find problems, which I could not even imagine 
>> without this work done.
>
>
> If this is a working prototype, why are you asking whether you can 
> check it in?

Because 2.0 is frozen.
I like NS proposal to build a public branch, and will follow it. After 
other people review my changes and if they also treat them useful, they 
will be used in 2.0.

Alex.