|
The book is called "HIPAA Security and Auditing for
Oracle".from Rampant TechPress. Although it is targeted towards the
organizations and individuals in US healthcare scene affected by the new
law HIPAA, the books is a handbook for security and auditing in Oracle
context with lots of scripts and real life examples. Don Burleson is the
co-author and we are trying to cover the details of security and auditing as
related to Oracle DBAs, developers and architects, leaving the stuff
related to other professionals, e.g. firewall setup, etc.
----- Original Message -----
Sent: Thursday, June 19, 2003 3:59
PM
Subject: Re: Re: Passwords and
authentication
what will be the name of your book? when will it be out? you
have an extract of what it will cover yet?
>
> From: "Arup
Nanda" <[EMAIL PROTECTED]>
> Date:
2003/06/19 Thu PM 03:31:43 EDT
> To: Multiple recipients of list
ORACLE-L <[EMAIL PROTECTED]>
>
Subject: Re: Passwords and authentication
>
> Passwords and
authenticationMladen,
>
> Thanks for bringing it up. In my book I
will cover the VPD (vitual private database) in detail and will explain how to
use the application user model into making a secure authentication and
authorization model. Label security is nothing but a specialized tool based on
the more general VPD. Most security conscious organizations will probably like
VPD more as it provides more flexibility in defining who sees what? OLS is
narrower in focus, a carry over from the old CIA project where each record in
a table was treated like a file with a security level and persons were
assigned cklearance levels. The check was whether user's clearance is greater
than or equal to the record's (or the docuemnts) clearance. The authorization
requirements were simple.
>
> Most real life system will most
likely have different and more complex requirements, though. Instead of plain
simple levels, your records will have to be verified against a lot of
parameters. For instance, in your database (Oxford Health), you may have a
senior business analyst (John Napoli) with authorization to see claims that
are (i) from a list of providers he is approved to see, (ii) below $10000,
(iii) for procedure codes that are not protected by HIPAA's protected health
information and perhaps a lot more. This is not as simple as assigning a level
to a row, but a rather complicated set of where conditions applied at the
runtime. VPD addresses that issue. Along with application context, you will
have the toolbox to build a complete iron-clad authentication and
authorization system.
>
> Hope this helps.
>
> Arup
Nanda
> www.proligence.com
>
>
>
> ----- Original Message -----
> From:
Gogala, Mladen
> To: Multiple recipients of list ORACLE-L
> Sent: Thursday, June 19, 2003 12:45
PM
> Subject: RE: Passwords and authentication
>
>
> There is also label security option which is
present on Enterprise Edition CD. That would
> alleviate
the need for manual encryption because the table cannot be seen unless there
is
> sufficient security clearance. Also, logging in from
SQL*Plus can be disabled from the USER_PRODUCT_PROFILE. Connected to that, is
anybody on this list using label
> security? Does anybody
have experience with it? Arup, you are writing a book about security
> in Oracle 9.2 and I hope that you will cover label
security.
>
> Mladen Gogala
>
Oracle DBA
> Phone:(203) 459-6855
>
Email:[EMAIL PROTECTED]
>
> -----Original
Message-----
> From: Arup Nanda
[mailto:[EMAIL PROTECTED]
> Sent: Thursday,
June 19, 2003 12:15 PM
> To: Multiple recipients
of list ORACLE-L
> Subject: Re: Passwords and
authentication
>
>
> Raj,
>
> My first question will be how you would want
to pass the encrypted password. sqlplus <username>/<encyptedpass>?
But won't the encrypted password be known before making the connection? If so,
then the user who will encrypt the password will also know how to decrypt
them. What's the advantage in doing that?
>
> Are you concerned someone sniffing the
network uncovers a clear password? If so, have you considered network security
with password encryption by Oracle Net?
>
> If that is not the concern but rather you
don't want the users to know the real password, here is a solution you might
be interested. It's part of a elaborate application security design. Please
read on if you are interested.
>
> You
would have user called SECUSER with only table APP_USERS. The table has two
columns - APP_USER and APP_PASS, in encrypted manner, with Triple DES
Encryption. The user also has one function - check_app_password, which accepts
two parameters - the userid and the password and returns a string. The return
value is YES is the password supplied is correct and NO, if it isn't. It does
not shw the correct password, ever; just shows if the supplied password is
correct or not. This function is defined as DEFINER rights. All users get an
execute privilege on this function, nothing else on the rest of the objects of
the SECUSER user.
>
> Inside the
function, the password is retrieved from the table, decrypted with the key
inside the procedure and matched with the supplied one. Another function is
provided to encrypt the password using teh same key. For more ecurity, the
userid and password combination can encrypted, not just the password. If you
want I can give you the code for the functions.
>
> When the app user connects, the connection is
done through a generic id, that, after the conenction, validates the password
using the function and authenticates the user. If the password is not correct,
the user is booted out.
>
> Now comes
other issues - fine grained access control and fine grained auditing. These
features need to have a sepcific named database user. However, that can be
easily fixed by setting up an application context and passing the app_user
value to a context attribute. This attribute can now be tracked, rather than
the userid.
>
> Hope this helps.
>
> Arup Nanda
>
www.proligence.com
> ----- Original
Message -----
> From: Jamadagni,
Rajendra
> To: Multiple recipients
of list ORACLE-L
> Sent: Thursday,
June 19, 2003 9:19 AM
> Subject:
Passwords and authentication
>
>
> Is it possible to connect to
database using encrypted passwords? Using sqlplus?
>
> Thanks
> Raj
>
--------------------------------------------------------------------------------
> Rajendra dot Jamadagni at
nospamespn dot com
> All Views
expressed in this email are strictly personal.
> QOTD: Any clod can have facts,
having an opinion is an art !
>
>
>
Mladen,
Thanks for bringing it up. In my book I will
cover the VPD (vitual private database) in detail and will explain how to use
the application user model into making a secure authentication and
authorization model. Label security is nothing but a specialized tool based on
the more general VPD. Most security conscious organizations will probably
like VPD more as it provides more flexibility in defining who sees what? OLS
is narrower in focus, a carry over from the old CIA project where each record
in a table was treated like a file with a security level and persons were
assigned cklearance levels. The check was whether user's clearance is greater
than or equal to the record's (or the docuemnts) clearance. The authorization
requirements were simple.
Most real life system will most likely have
different and more complex requirements, though. Instead of plain simple
levels, your records will have to be verified against a lot of parameters. For
instance, in your database (Oxford Health), you may have a senior business
analyst (John Napoli) with authorization to see claims that are (i) from a
list of providers he is approved to see, (ii) below $10000, (iii) for
procedure codes that are not protected by HIPAA's protected health information
and perhaps a lot more. This is not as simple as assigning a level to a row,
but a rather complicated set of where conditions applied at the runtime. VPD
addresses that issue. Along with application context, you will have
the toolbox to build a complete iron-clad authentication and
authorization system.
Hope this helps.
Arup Nanda
----- Original Message -----
Sent: Thursday, June 19, 2003 12:45
PM
Subject: RE: Passwords and
authentication
There is also label security option which is
present on Enterprise Edition CD. That would
alleviate the need for manual encryption because
the table cannot be seen unless there is
sufficient security clearance. Also, logging in
from SQL*Plus can be disabled from the USER_PRODUCT_PROFILE. Connected to
that, is anybody on this list using label
security? Does anybody have experience with it?
Arup, you are writing a book about security
in
Oracle 9.2 and I hope that you will cover label
security.
Mladen Gogala
Oracle DBA
Phone:(203)
459-6855
Email:[EMAIL PROTECTED]
Raj,
My first question will be how you
would want to pass the encrypted password. sqlplus
<username>/<encyptedpass>? But won't the encrypted password be
known before making the connection? If so, then the user who will encrypt
the password will also know how to decrypt them. What's the advantage in
doing that?
Are you concerned someone sniffing the
network uncovers a clear password? If so, have you considered network
security with password encryption by Oracle Net?
If that is not the concern but rather you
don't want the users to know the real password, here is a solution you
might be interested. It's part of a elaborate application security design.
Please read on if you are interested.
You would have user called SECUSER with only
table APP_USERS. The table has two columns - APP_USER and APP_PASS, in
encrypted manner, with Triple DES Encryption. The user also has one
function - check_app_password, which accepts two parameters - the userid
and the password and returns a string. The return value is YES is the
password supplied is correct and NO, if it isn't. It does not shw the
correct password, ever; just shows if the supplied password is correct or
not. This function is defined as DEFINER rights. All users get an execute
privilege on this function, nothing else on the rest of the objects of the
SECUSER user.
Inside the function, the password is
retrieved from the table, decrypted with the key inside the procedure and
matched with the supplied one. Another function is provided to encrypt the
password using teh same key. For more ecurity, the userid and password
combination can encrypted, not just the password. If you want I can give
you the code for the functions.
When the app user connects, the connection is
done through a generic id, that, after the conenction, validates the
password using the function and authenticates the user. If the password is
not correct, the user is booted out.
Now comes other issues - fine grained access
control and fine grained auditing. These features need to have a sepcific
named database user. However, that can be easily fixed by setting up an
application context and passing the app_user value to a context attribute.
This attribute can now be tracked, rather than the userid.
Hope this helps.
Arup Nanda
----- Original Message -----
Sent: Thursday, June 19, 2003 9:19
AM
Subject: Passwords and
authentication
Is it possible to connect to database
using encrypted passwords? Using sqlplus?
Thanks
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn
dot com
All Views expressed
in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art
!
|
