RE: Security and SSD

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