Re: Access Limitation

Hi Tanel

some comments in line..:-)

In article <3e596441_1_at_news.estpak.ee>, Tanel Poder <tanel@?.com> writes
>Hello!
>
>You might code your application to add a prefix or suffix to the
>username/password which a user types in and then send this information to
>Oracle.
>
>When users don't know the prefix/suffix, they can't log on to db either. Of
>course the users can monitor network traffic and find out the secret.
>

There are many ways to find out database user account names, even just looking at ALL_USERS would soon get someone thinking if the username had something extra in front or after it. It wouldn't take long to determine the extra bit from a list of user names.

>For that you could use some kind of complex algorithm for changing the
>password prefix in DB every time a user logs on, using AFTER LOGON trigger.
>You have to use autonomous transaction for that. When using trigger to
>change the password, sniffing sql*net wont help, because the alter user
>clause isn't issued on client side. Of course the application has to be
>aware of the same algorithm, that it knows which prefix to add next time.
>

changing your password every time you log in or worse username, what about audit and accountability, it would be difficult to track anything with changing user accounts, what about the old accounts? drop them?

>Issues:
>
>1) *any* client side application can still be debugged/reverse-engineered,
>thus revealing the algorithm
>2) since every DDL issues an implicit commit, heavy commiting can occur in
>(web) environments, where logon is made for every request (actually I'm not
>sure whether a commit record is written to logs and lgwr posted when
>transaction is zero size - hasn't even started. It's too late here to test
>either. Anyone?)
>3) if sql*net is traced on client side and logon *doesn't* succeed for some
>reason, then the afterupgrade trigger doesn't fire - the same password
>remains and the user can log on with that password once (once is enough to
>be worried about).
>
>Actually this problem could be relieved by auditing failed logon attempts
>and creating a trigger for AUD$ table

It is not possible to create triggers on SYS objects, it is possible to move the table to another user, add a trigger and have a synonym for SYS to access it. This of course wouldnt be supported by Oracle!

>- when a non successful logon is
>tried, the trigger automatically changes the user's password to next one, of
>course the application has to be aware of that as well.
>
>Because encrypting is the *only* real protection for information when one
>has physical access to the hardware (client + network connection to server),
>it might be reasonable to use private-public key encryption to propagate the
>new password to client. But that would require writing the algorithms (maybe
>obfuscation toolkit could be used) for both server side triggers and client
>side. Also it would require a mechanism for getting the encrypted password
>to the client, this could be achieved with a dummy account with create
>session privilege and one table for storing the encrypted passwords. This
>means, two Oracle logins have to be made when a user logs on - first one for
>getting the new encrypted password to client (and setting the appropriate
>pwd for user in Oracle) and second is the actual login to the right schema.
>

This is the sort of thing SAP does for logins, they encrypt with a weak algorithm though.

Kind regards

Pete

-- 
Pete Finnigan

Email : pete_at_peterfinnigan.demon.co.uk
Email : pete_at_petefinnigan.com

Web site: http://www.petefinnigan.com

Independent consultant specialising in Oracle security. Pete Finnigan is the 
author of the recently published book about Oracle security from the SANS 
Institute "Oracle security Step-by-step (A survival guide for Oracle security)" 
- see http://store.sans.org for details.

Some recently published articles include:

http://online.securityfocus.com/infocus/1644 - "SQL injection and Oracle - part 
one"

http://online.securityfocus.com/infocus/1646 - "SQL injection and Oracle - part 
two"