× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I would think you would use an industrial-strength encryption routine
which should give you the same result every time you encrypt the same
cc#. And you could just as easily check for unusual use of the encrypted
number as you could the unencrypted number. I'm almost positive that
some states (probably California) have legislation banning the
electronic storage of credit card numbers which are not one-way
encrypted.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Bronski
Sent: Wednesday, February 19, 2014 8:44 AM
To: Midrange Systems Technical Discussion
Subject: Re: Security and SSD

As I said, if you used a salted hash you couldn't do the lookup. And as
for the cc issuer being the only one looking for fraudulent
activity...you don't work in retail do you?

On 2/19/2014 2:39 PM, Briggs, Trevor (TBriggs2) wrote:
Which is why you wouldn't use a basic hash to do the encryption,
surely.
And...a company looking for unusual card activity would surely be the
card issuer since they would probably be the only entity that would be
privy to every transaction put through on the card.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Bronski
Sent: Wednesday, February 19, 2014 8:33 AM
To: Midrange Systems Technical Discussion
Subject: Re: Security and SSD

If all you're using to "encrypt" the cc# is a basic hash then all
you've

done is replace the number with a token. A simple dictionary attack
will

reveal the cc#'s pretty quickly. If you've salted your hash then the
lookup you propose becomes much more difficult. There are many real
world reasons to maintain cc#s (or their tokens)...fraud detection
(e.g
spotting unusual card activity) being just one.

On 2/19/2014 2:18 PM, Briggs, Trevor (TBriggs2) wrote:
You tell me the credit card number you want to use for a transaction,
I
encrypt it and compare it with the encrypted number on file. If it's
the
same, then your card is valid. Unless you're the actual financial
institution that issued the credit card number there's no reason for
you
to want to know what the (unencrypted) number actually is.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 19, 2014 8:16 AM
To: Midrange Systems Technical Discussion
Subject: RE: Security and SSD

Then what's the point of recording it? If it can never be retrieved
or
utilized?


Rob Berendt


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.