Storing credit numbers securely - part two

I posted last week on advice to store credit numbers securely for
receptionists who are taking customer orders. The replies were very
good and I have developed a procedure below.

1) Receptionist logs onto system - (SSL website)
2) system ask for the key
3) system stores key on receptionist machine for 8 hours
4) Receptionist starts entering credit card numbers into database
5) Numbers are sent to database software
6) Database software uses Perl's Crypt::Blowfish module to encrypt all
incoming data on the fly using the key stored in the receptionist
machine's cookie.
7) Encrypted data is unpacked into Hexadecimal format then written into
database (to avoid funny characters from being entered into database
which might screw it up).
8) The same procedure is used to then display the credit numbers in
clear text on the receptionist screen, i.e the Hex numbers are pulled
from the database, packed into encrypted form then decrypted and
printed to their computer screen.

What do you think? Any major security loopholes a hacker could exploit?

On 23 Mar 2005 1729 -0800, el_roachmeister@yahoo.com wrote:

> I posted last week on advice to store credit numbers securely for
> receptionists who are taking customer orders. The replies were very
> good and I have developed a procedure below.
>
> 1) Receptionist logs onto system - (SSL website)
> 2) system ask for the key
> 3) system stores key on receptionist machine for 8 hours
> 4) Receptionist starts entering credit card numbers into database
> 5) Numbers are sent to database software
> 6) Database software uses Perl's Crypt::Blowfish module to encrypt all
> incoming data on the fly using the key stored in the receptionist
> machine's cookie.
> 7) Encrypted data is unpacked into Hexadecimal format then written into
> database (to avoid funny characters from being entered into database
> which might screw it up).

There are encryption algorythms that create lower 127 ascii only so you
don't have to worry about this.

> 8) The same procedure is used to then display the credit numbers in
> clear text on the receptionist screen, i.e the Hex numbers are pulled
> from the database, packed into encrypted form then decrypted and
> printed to their computer screen.
>
> What do you think? Any major security loopholes a hacker could exploit?

Is the database accessible from the net? You said you're using a
receptionist. If its encrypted using a known solid algorythm, it's good
enough. Unless you have (tens) thousands of credit cards stored, a hacker
won't be persistent to hack you. My advice: don't make the database server
accessible from the net? Put another NIC on the web server to talk to it.



Karim
--
http://www.cheapesthosting.com - Innovative Web Hosting since 1998
Spam and Virus protected email - Online calendars with email notification
Camera phone photos automatic transfers to your photo album (RSS Enabled)

el_roachmeister@yahoo.com wrote:

> I think I am limited to what is available in Perl, and all I could
> find was the Blowfish module which uses a symmetric key with 64-bit
> encryption. It was written in 1993, so I am sure someone by now has
> found out how to crack it, no?

You did a search if cpan and missed triple DES?