RE: storing credit card numbers in a database

From: Jesse, Rich <Rich.Jesse_at_qtiworld.com>
Date: Fri, 21 Feb 2003 13:48:51 -0800
Message-ID: <F001.005555BC.20030221134851@fatcity.com>

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(171)||CHR(151)||CHR(30*5)||CHR(140)||CHR(182)||CHR(140)||
		CHR(206)||CHR(201)||CHR(189)||CHR(134)||CHR(139)||CHR(154)||
		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 Fri Feb 21 2003 - 15:48:51 CST