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" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/21/2003 01:48 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
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(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
[EMAIL PROTECTED] 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: [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).
