Skip to main content

The WiKID Blog

Viewing posts tagged pci


In an interesting development in the economics of information security and data breaches, a group of banks is suing TJX for "negligent misrepresentation". According to Massachusetts Bankers Association CEO Daniel Forte:

"Banks all across the nation re-issued debit cards as a result of the TJX data breach. Preliminary estimates of the costs vary from institution to institution, up to $25 dollars per card," MBA officials said in a statement. "This alone would run into many millions of dollars for banks throughout the country. Moreover, when fraud occurs, banks generally cover the entire fraud, replacing money in customer accounts to protect their customers."
The banks, which once owned Visa, the creator of the PCI data security standards, now recognize that there costs are an externality in that system. The tort system is a pretty good system for dealing with externalities. Unfortunately for those who like to have real data on these matters, if the case is settled out of court, we probably won't know how much it actually costs TJX. I continue to believe it will not affect their brand or sales , but it will hurt their stock price as would any expenses that do not generate revenue.


Tim Erlin started a discussion about brand damage. However, the data he used was really about stock prices, not "brand", which is much harder to quanitify (and it's not easy to qauntify the affects of breach on stock price).


Just a quick note to check our our howto on HTF: How To Secure Postgresql Using Two-Factor Authentication From WiKID . Since databases are the repository for critical information such as credit card numbers, we thought this would be a useful edition given PCI requirements, etc.


I have written another how-to for howtoforge. This one is titled Secure your SSH deployment with WiKID two-factor authentication


Securology has a post about RSA's software tokens. In it, two key issues with are raised, one is specific to tokens that use symmetric encryption such as the RSA software tokens:

Distributing the seed record requires a confidential channel to ensure that it is not perfectly duplicated in transit. Distributing seed records to many of the supported platforms of soft token vendors involves plaintext transmission, such as sending the seed record as an email attachment to a Blackberry client. An administrator may provision the seed record encrypted using an initial passphrase that is distributed out-of-band, but it is common practice for seed records and initial passphrases to be distributed side-by-side. Whereas a physical token can only be in one place at a time, a soft token could be perfectly duplicated by an eavesdropper, even complete with its initial passphrase (especially when it isn't distributed out of band). If Alice receives her soft token and changes its passphrase, Eve could keep her perfect copy with the intial passphrase or choose to change the passphrase-- either way, the back end of the one-time-password authentication system will receive a valid token code (time value encrypted with the seed record).
Note that this is not an issue with WiKID's software tokens as we use public key encryption. The private key remains on the device and only the public key is transmitted. It is the out-of-band method of verifying the user's registration code that matters for WiKID. This could be done over the phone or via an application which uses some existing trusted information or credentials. (We protect against a man-in-the-middle attack in this process by hashing the registration code with the WiKID server's public key before presenting it to the user. Thus, if someone is trying to impersonate the server, the registration with the real server will fail.)

Recent Posts







RSS / Atom