Re: Passwords and authentication
What about SQLNET.ENCRYPTION_TYPES_CLIENT= (rc4_256) SQLNET.ENCRYPTION_SERVER = accepted SQLNET.ENCRYPTION_CLIENT = requested SQLNET.CRYPTO_SEED = The quick brown fox jumps over the lazy dog. in sqlnet.ora - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 21:45 Passwords and authenticationRaj, 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 ! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Passwords and authentication
That is for encypting password while tranmitting over Oracle Net, the password itself must be entered in clear text. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, June 20, 2003 10:34 PM What about SQLNET.ENCRYPTION_TYPES_CLIENT= (rc4_256) SQLNET.ENCRYPTION_SERVER = accepted SQLNET.ENCRYPTION_CLIENT = requested SQLNET.CRYPTO_SEED = The quick brown fox jumps over the lazy dog. in sqlnet.ora - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 21:45 Passwords and authenticationRaj, 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 ! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Passwords and authentication
Title: Passwords and authentication Raj, My first question will be howyou wouldwant 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 !
RE: Passwords and authentication
Title: 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 PMTo: Multiple recipients of list ORACLE-LSubject: Re: Passwords and authentication Raj, My first question will be howyou wouldwant 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 !
RE: Passwords and authentication
Title: Passwords and authentication Label Security = Sometimes we need to compile forms against production instance (please don't ask) to resolve some really stupid issues. When compiling, the form has to be compiled with schema owner (again don't ask). As the production schema are locked down, we need a way to connect to compile. I do not want to set-up an elaborate scheme as mentioned by Arup, because this will _NOT_ be a regular feature. This all came into picture because the new release mechanism that we are testing ... you check in a form into PVCS, as it gets promoted to R_F_P, the DBAs would check it out, compile it and release it. And all three processes will be managed by event triggers in PVCS. The main use of using encrypted connection to connect to db is to compile forms and reports (from windows platform). Ok well, seems like a bit of impossible task to me ... to connect using the encrypted value from dba_users view. Thanks for the ideas though ... 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 ! -Original Message-From: Gogala, Mladen [mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 12:45 PMTo: Multiple recipients of list ORACLE-LSubject: 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 PMTo: Multiple recipients of list ORACLE-LSubject: Re: Passwords and authentication Raj, My first question will be howyou wouldwant 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
Re: Passwords and authentication
Title: Passwords and authentication 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 organizationswill 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 willmost 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 $1, (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 thetoolbox 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 PMTo: Multiple recipients of list ORACLE-LSubject: Re: Passwords and authentication Raj, My first question will be howyou wouldwant 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
Re: Passwords and authentication
Reginald, Could you explain how, please. Arup - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 12:05 PM Yes it is. RWB Reginald W. Bailey IBM Global Services - ETS SW GDSD - Database Management Your Friendly Neighborhood DBA 713-216-7703 (Office) 281-798-5474 (Mobile) 713-415-5410 (Pager) Rajendra.Jamadagn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent by:cc: [EMAIL PROTECTED] Subject: Passwords and authentication .com 06/19/2003 08:19 AM Please respond to ORACLE-L 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 ! (See attached file: ESPN_Disclaimer.txt) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
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 $1, (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
RE: Passwords and authentication
Title: Passwords and authentication Bummer! I was hoping for a commission from Oracle! Mladen Gogala Oracle DBA Phone:(203) 459-6855 Email:[EMAIL PROTECTED] -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 3:18 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Passwords and authentication Label Security = Sometimes we need to compile forms against production instance (please don't ask) to resolve some really stupid issues. When compiling, the form has to be compiled with schema owner (again don't ask). As the production schema are locked down, we need a way to connect to compile. I do not want to set-up an elaborate scheme as mentioned by Arup, because this will _NOT_ be a regular feature. This all came into picture because the new release mechanism that we are testing ... you check in a form into PVCS, as it gets promoted to R_F_P, the DBAs would check it out, compile it and release it. And all three processes will be managed by event triggers in PVCS. The main use of using encrypted connection to connect to db is to compile forms and reports (from windows platform). Ok well, seems like a bit of impossible task to me ... to connect using the encrypted value from dba_users view. Thanks for the ideas though ... 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 ! -Original Message-From: Gogala, Mladen [mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 12:45 PMTo: Multiple recipients of list ORACLE-LSubject: 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 PMTo: Multiple recipients of list ORACLE-LSubject: Re: Passwords and authentication Raj, My first question will be howyou wouldwant 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
RE: Re: Passwords and authentication
http://www.dba-oracle.com/bp/bp_titles.htm Look about in the middle of the page. -Original Message- what will be the name of your book? when will it be out? you have an extract of what it will cover yet? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: Passwords and authentication
Title: Passwords and authentication The book is called "HIPAA Security and Auditing for Oracle".from Rampant TechPress. Although it is targetedtowardsthe organizations and individuals in US healthcare scene affected by the new law HIPAA,the books is ahandbook 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 toOracle DBAs, developers and architects, leaving the stuff related to other professionals, e.g. firewall setup, etc. You can find an abstract of the book at http://www.dba-oracle.com/bp/bp_book11_audit.htm. The target date is September from Rampant website and December everywhere else. - Original Message - From: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L 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 $1, (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 use
RE: Re: Passwords and authentication
HIPAA Auditing for Oracle Database Security Nice. Well, Arup, Get to publishing! ;-) --Scott -Original Message- To: Multiple recipients of list ORACLE-L Sent: 6/19/03 3:19 PM http://www.dba-oracle.com/bp/bp_titles.htm Look about in the middle of the page. -Original Message- what will be the name of your book? when will it be out? you have an extract of what it will cover yet? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: Passwords and authentication
Thanks, Scott. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 6:04 PM HIPAA Auditing for Oracle Database Security Nice. Well, Arup, Get to publishing! ;-) --Scott -Original Message- To: Multiple recipients of list ORACLE-L Sent: 6/19/03 3:19 PM http://www.dba-oracle.com/bp/bp_titles.htm Look about in the middle of the page. -Original Message- what will be the name of your book? when will it be out? you have an extract of what it will cover yet? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
