Re: [Firebird-devel] Vulcan Joins Free World

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

Alex Peshkov wrote:

> Jim Starkey wrote:
>
>>
>> I put in a "short term hack" this is worth considering for the long 
>> run.  The account and password used to establish a connection for 
>> authentication are hard coded as  "AUTHENTICATOR" and "none", 
>> respectively.  The magic account is special cased by SecurityDb and 
>> (in theory) has no rights to do anything but respond to an 
>> fb_authenticate_user call (I say "in theory" because I haven't 
>> actually implemented the restrictions).  While this smacks of 
>> politcally/correct, that hack had pure god status while 
>> AUTHENTICATOR/none has no rights at all.  I implemented the hack in 
>> Vulcan as the best I could think of at the time, but I think it's 
>> OK.  It does the job, it doesn't open any security vulnerabilities 
>> (fb_authenticate_user gets called for any attach anyway), and doesn't 
>> present any new avenues for denial of service attacks.  It seems 
>> simple and crude, but also simple and elegant.
>>
>
> I see a problem with this solution - AUTHENTICATOR can't be given 
> absolutely no rights. He must have access to RDB$USERS table and must 
> be able to read hashes from it. How do you plan to make it impossible 
> to attach to the server with this account?

Actually, the account doesn't require access to RDB$USERS.  The code 
inside SecurityDb::authenticateUser runs against the system transaction, 
not the user transaction, so access is no problem.

> May be instead of hack it will be better to have two entrypoints to 
> attach_database() - internal and external. Internal one has one 
> additional flag, making it possible to attach to database internally 
> (and SecurityDatabase authentication will use it). In this case no 
> security checks are done. All external attachments run threw the 
> normal authentication procedure.

I'd like to avoid this.  Flags (and globals) are one of mother nature's 
little suggestions that you're doing something wrong.

> BTW, internal attachment is also used in tra.cpp to start automatic 
> sweep process. And it may be started with any database, not only 
> security.

There are better ways to do this.

>
> There are two things that are necessary and should be
>
>> sufficient.  First and foremost, there should be an active mechanism 
>> to notify a system administrator that the system is under attack.  
>> Logging it isn't sufficient.  
>
>
> But how? May be configurable command that should be executed when the 
> system is under attack is enough?

Interesting question.  Maybe we should make an "underAttack" part of the 
security plugin API.  The default impementation should probably be to 
look for an smtp server name and email address in the "security" object 
in the configuration file and if present send him/her/it email.  Calling 
his or her cell phone in the middle of the night seems a little extreme 
and likely to cause trouble with spouses and pets.

>
> Second, and only after the system has determined
>
>> it is under attack, introduce a long delay (a minute?) before 
>> returning a login failure.
>>
>
> I've added minimum support of this feature in 2.0 - but delay was 
> chosen to be 10 seconds and it's hardcoded for today. I think that 
> having configuration entry for a feature that may be seriously 
> modified in a nearest future is not good. Frin the point of rejecting 
> attempts to remotely brutforce passwords 10s delay seems to be enough.

I think you're right.  But haven't we reversed roles?  I'm supposed to 
argue for the simple, you for the complex.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376