Paul Gilmartin wrote: >Can it deal with validity constraints such as the credit card check digit: > http://en.wikipedia.org/wiki/Luhn_algorithm
Of course...it will optionally recalculate it, leave it as-is, or force it invalid (another way to tell that the data is masked-although it turns out that there are actually cards in the wild with invalid Luhn checksums, but most companies won't accept those anyway). You can also tell it to just mask specific parts of a card number-for example, leave the BIN (first n digits) and the last 4 in plaintext, and just encrypt the middle 6, which are the actual account number. Lots of options. >...? And I understand that some 9-digit keys eschew any values >that contain the sequence "666" as a courtesy to the client. >(Actually at the client's option, but suppose it were to be made a >rule.) Never seen that requirement from any of our customers, including Fortune 50 and three of the top ten card processors. Actually, since the masked data is never seen by any customers, I'm not sure that it would even matter-would it? -- ...phsiii Phil Smith III p...@voltage.com<mailto:p...@voltage.com> Voltage Security, Inc. www.voltage.com<http://www.voltage.com> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
