Re: [Firebird-devel] crypt plugins

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

Jim Starkey wrote:

>
>
> Alex Peshkov wrote:
>
>> Hi!
>>
>> During last two weeks I implemented crypt plugins facility for 
>> firebird engine. This work was discussed privately with Paul and Dmitry.
>
>
> Private "security reviews" are stupid and short sighted.  Security is 
> either robust or a joke.  Security isn't robust until many interested 
> eyes and minds have reviewed the set of problems and prospective 
> solutions.  Are you trying to solve real problems and just looking for 
> a circle to run around?  

It seems to me that I've described them in my letter - we can't prevent 
stealing hashes of passwords (at least for CS on posix). Current hashes 
may be relatively easy brutforced on a modern CPUs. Therefore let's try 
to make them hard to brutforce. The best way is to let people use that 
hashes they trust. Therefore - crypt plugins.

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

> Why do you care is J. Random User reads a secure hash of a password?  
> He can't do anything with it?

Appears with exesting hashes - can. It's possible to brutforce them.

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

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

> What earthly good is a patch that blocks readers if a user can copy 
> the database file and compile a version of Firebird without the patch?

I thought that patch is well known. It does absolutely nothing with 
engine - only database modification. For details please 
http://www.volny.cz/iprenosil/interbase/

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

>
> I'm really sorry if it's an inconvenience to write up and present a 
> prospective architecture for others to review, but that's the only way 
> to make a system secure.
>
> The security architecture is more important that the code.  It should 
> come first.
>
> I don't want to see any "security" enhancements checked into anything 
> until we have had an opportunity to review the big picture first.  
> Phasing in a secure hash make sense.  I don't see that any of the rest 
> makes sense at all.

Sorry, it simply doesn't work without other changes. I tried to explain 
why, may be I expressed my thought not well enough, but I'd like to see 
what real problems this change creates, not only common words.
I wanted to solve one main problem - give users an ability to use such 
hashes for passwords that they want. I think my design solves this 
particular problem. I don't know, what addtional problems it may raise 
for future security design. Moreover, with hash calculation, moved from 
client to server, future security review seems easier - for example, 
implementation of auth plugins.

Alex.