I'm rather surprised that I so seldom see someone suggestion using
one's own public key to encrypt the data, and your private key to
decrypt the data - are people just not using PGP and the like?
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden mailto:[EMAIL PROTECTED]
On Tue, 08 May 2001 06:09:49 -0400 (EDT), Larry W. Virden
[EMAIL PROTECTED] wrote:
I'm rather surprised that I so seldom see someone suggestion using
one's own public key to encrypt the data, and your private key to
decrypt the data - are people just not using PGP and the like?
We do exactly
Subject: Re: Credit Card DB Encryption Methodology
Ok, I've been thinking about this. And in the case of returns or credits,
I think we could this:
On the website as the customer requests a return, they must enter their
password. I store this encrypted with the RMA number (or some other
[EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Thursday, May 03, 2001 3:52 PM
Subject: Credit Card DB Encryption Methodology
Ok, I've been reading the last few threads on this and pondering the best
way to approach this scenario (storing CC in DB) and I've come up with the
following idea
server.
jon
- Original Message -
From: Tony Schreiber [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Thursday, May 03, 2001 3:52 PM
Subject: Credit Card DB Encryption Methodology
Ok, I've been reading the last few threads on this and pondering the best
way to approach
Message -
From: Tony Schreiber [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 11:43 AM
Subject: Re: Credit Card DB Encryption Methodology
Yes, but that's a physical architecture issue. I'm just trying to address
the software side. I'm surprised there haven't been
-
From: Tony Schreiber [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 11:43 AM
Subject: Re: Credit Card DB Encryption Methodology
Yes, but that's a physical architecture issue. I'm just trying to address
the software side. I'm surprised there haven't been more
Yes, I agree your method is much more secure, just harder to snippetize ;-)
jon
- Original Message -
From: Tony Schreiber [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 4:25 PM
Subject: Re: Credit Card DB Encryption Methodology
That's what I'm doing
Schreiber [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 4:25 PM
Subject: Re: Credit Card DB Encryption Methodology
That's what I'm doing, but the problem with that is that you have to store
the key, unencrypted, somewhere on the server. And one key decrypts your
On 3 May 2001, at 15:52, Tony Schreiber wrote:
1) The User's password is stored as a one-way HASH.
2) The Credit Card info (list of cc number,exp date and
verification number) is stored as an ENCRYPTED string with the
User's raw password as the key.
That's fine as long as the only reason
1) The User's password is stored as a one-way HASH.
2) The Credit Card info (list of cc number,exp date and
verification number) is stored as an ENCRYPTED string with the
User's raw password as the key.
That's fine as long as the only reason you're storing the
credit card number is
So what are you doing in those cases, do you have to contact the customer?
Curious...
By the way, I think you've done a great job of dealing with CC encryption.
Good approach. Even though the major on-line vendor site that we've written
doesn't do credit card processing, we still prompt for the
Ok, I've been thinking about this. And in the case of returns or credits,
I think we could this:
On the website as the customer requests a return, they must enter their
password. I store this encrypted with the RMA number (or some other
associated id) as the key. Once the return is processed,
Ok, I've been reading the last few threads on this and pondering the best
way to approach this scenario (storing CC in DB) and I've come up with the
following idea:
1) The User's password is stored as a one-way HASH.
2) The Credit Card info (list of cc number,exp date and verification
number) is
14 matches
Mail list logo
