Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: storing credit card numbers in a database
None taken! :)
Rich
-----Original Message-----
Sent: Friday, February 21, 2003 5:44 PM
To: Multiple recipients of list ORACLE-L
No offense Rich, but I think a crypto expert would make short work of decrypting this.
Jared
"Jesse, Rich" <Rich.Jesse_at_qtiworld.com>
Sent by: root_at_fatcity.com
02/21/2003 01:48 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: Subject: RE: storing credit card numbers in a database
Even a half-arsed encryption (e.g. 255-ascii(each_char) for 1-byte
languages) in your code can make the wrapped procedure extremely difficult
to crack. Keep in mind that the assignment of the hashed value shouldn't
be
in the DECLARE section, because it's location in the wrapped procedure
will
give away the fact that it's hashed. For example:
create or replace procedure bleah as
v_hashed_pass VARCHAR2(5) := chr(180)||chr(190)||chr(234)||chr(123); v_hash VARCHAR2(16); v_pass VARCHAR2(16); BEGIN v_hash :=
CHR(140)||CHR(222)||CHR(222)||CHR(222); for x in 1..length(v_hash) loop v_pass := v_pass||CHR(255-ascii(substr(v_hash,x,1))); end loop; dbms_output.put_line(v_pass);end bleah;
The "v_hashed_pass" is in there only for obfuscation, since each literal
isn't wrapped. Notice also the "30*5" in the assignment of v_hash. Since
the "5" literal was used in the assignment of v_hashed_pass, it'll throw
off
anyone trying to reverse engineer the wrapped code. You could do all
sorts
of stuff like this to make it next-to-impossible to crack.
Or you could just use Pro*C and secure the code, since you'd have to
secure
the unwrapped package somewhere anyway... :)
Rich
Rich Jesse System/Database Administrator rich.jesse_at_qtiworld.com Quad/Tech International, Sussex, WI USA
-----Original Message-----
Sent: Friday, February 21, 2003 2:00 PM
To: Multiple recipients of list ORACLE-L
Look into the DBMS_OBFUSCAITON package. I used it to encrypt passwords for a system management app and it works well. The only problem is that you need an encryption key for the programs to use. If anybody knows how to read the ALL_SOURCE view they will be able to find your key and decrypt the data. You can use the 'wrap' utility to try to hide it and then protect the un-wrapped source code up the ying-yang but if you use a text variable like I was crazy enough to to, the damn literal gets put into the wrapped source. You can use an expression of some sort but it's going to have to generate the key reliably each time and then what happens if it doesn't some day and all of your data becomes unreadable??? the literal starts looking better....but you have to hide it well and protect it from being compromised.
Not to toally turn you off of the package....but I was coming at it from the angle that I was trying to protect the information from somebody like me =8-)
HTH Jeff Herrick
On Fri, 21 Feb 2003, Chris Stephens wrote:
>
> I've been asked to find out a way to encrypt credit card numbers and
store
> that encrypted string in the database. ...any oracle functions or
> functionality to do this? ....or would we have to encrypt the numbers in
the
> application and then pass that string to the database?
>
> We don't want anyone to be able to get to the numbers even if they have
> access to the table in which it is stored.
>
> Thanks for any input
> chris
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jesse, Rich INET: Rich.Jesse_at_qtiworld.com 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: ListGuru_at_fatcity.com (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).Received on Mon Feb 24 2003 - 09:45:08 CST