Re: [Firebird-devel] Vulcan Joins Free World

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

Alex Peshkov wrote:

> Jim Starkey wrote:
>
> The problem is that when you attach to security database with user 
> account engine needs to check wheather given account may access given 
> database. To perform this check engine must attach to security 
> provider, where it sees that security provider for given database is 
> database itself, therefore it must attach to security database with 
> some account - I see a kind of deadlock here. Linked list of internal 
> handles is used in fb 1.5 in order to solve this deadlock. If database 
> handle is internal, wee need not check validity of account 
> (non-existent "authenticator" with password "none"), therefore attach 
> to database operation is possible for internal handle.

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.

>
>
> Using current account to attach to security database has one more 
> long-term problem. If we plan to automatically lockout user in case of 
> abnormal activity (multiple attempts to brut-force password, for 
> example) engine should have write permissions on security database, 
> which is hardly possible with regular account.
>
I'm not sure that lockouts are a good solution.  Among other things, it 
a complete surrender to a denial of service attack, which an only 
encourage more.  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.  Second, and only after the system has determined 
it is under attack, introduce a long delay (a minute?) before returning 
a login failure.

Interbase had runtime license enforcement, but we wanted users the be 
able to the system under emergency conditions, which included expiration 
of temporary demo licenses.  A friend suggested a neat scheme.  When a 
user attached an unlicensed database, he/she got a "stop stop stop" 
message with the standard carrot and stick message, followed by a line 
indicating how long the system delay.  Each attachment increase the 
delay time by one second.  I don't know of anybody who could stand to 
wait 20 seconds before calling us up and going legit.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376