Re: [Firebird-devel] crypt plugins

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

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?  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?  Why do you 
care is J. Random User reads a secure hash of a password?  He can't do 
anything with it?  Trying to hide the hash is completely pointless.  
Hiding it in an ineffective manner is less than pointless.  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?

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