Re: [Firebird-devel] crypt plugins

[Edward F. <ed...@cd...>]

It doesn't matter if you encrypt passwords with crypt,MD5, or SHA.  The 
problem here isn't the fact that these things are weekly encrypted.  The 
problem is the fact that users (not just the server) can view all the 
encrypted hashes.  This makes brute forcing anybody's insecure password, 
achievable in a VERY finite amount of time.  Please consider changing 
the method of authentication to something along the lines of SRP 
(http://srp.stanford.edu) or SASL (http://www.ietf.org/rfc/rfc2222.txt) 
for modular authentication.  And then make the users database unreadable 
to clients.

Alex Peshkov wrote:
> Jim Starkey wrote:
> 
>>
>>
>>> 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.
> 
> 
> In one honey-net report I've seen even much smaller digits, for four 
> experimental boxes it varied from 19 minutes to 25 hours.
> 
>> However, even without hackers, any PC user can put his ethernet board 
>> into promiscuous mode and get all traffic.  
> 
> 
> This means - if you want secure network, use switches, not hubs.
> 
>> 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?
>>
> Certainly not, that's why if I need remote connection to firebird, I 
> always use zebedee.
> 
>> 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.
>>
> Agreed, but I can protect from loss of passwords in network without 
> moification of engine (as described above).
> 
>>>
>>>>
>>>> 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.  
> 
> 
> 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.
> 
>> 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.
>>
> Sometimes it seems that they didn't think very much about many things.
> Could they that time :
> - calculate hashes on server, not client,
> - add a feature to use plugins for creating hashes,
> interbase might smoothly migrate from crypt to MDn and later to SHA-n.
> 
>>>>
>>>> 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.
> 
> 
> 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'?
> 
> But on a box, where I tried to reproduce a problem it was a setting to 
> restrict database access in firebird.conf. Certainly, there was no path 
> on mounted disk in restrict-list. Therefore I was not able to get access 
> to security database using remote mount. But out-of-the-box installation 
> really makes it possible to do this trick. On the other hand, will 
> security database be trashed after such access? If yes, wrong hash in it 
> doesn't make any difference.
> 
>>
>>> 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.
>>
> No, crypt was mentioned there. It's some misunderstanding, sorry. I 
> meant crypt/DES.
> 
> Alex.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> Firebird-Devel mailing list, web interface at 
> https://lists.sourceforge.net/lists/listinfo/firebird-devel