Re: Access Limitation

Hi!

Thanks for useful comments, Pete!

Yes, the username prefix should be permanent, otherwise things would get too complicated. I think that was what I wrote - about changing password every time user logs on. I see no real problems with that.

And yes, the username prefix could be found out from ALL_USERS, but the application shouldn't allow querying it. Of course, if anyone is able to bypass applications once, then the big secret could be revealed again :(

The tip on triggers on SYS objects was a good one, I didn't think about that.

Tanel.

"Pete Finnigan" <pete_at_peterfinnigan.demon.co.uk> wrote in message news:nLBxB$AB+pW+EwkR_at_peterfinnigan.demon.co.uk...
> 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"
Received on Mon Feb 24 2003 - 19:11:23 CST