of course, the other problem is that a substantial part is the "customer at risk" (not just merchant at risk exposure as the result of any merchant implementation short comings) .... and there is currently no obvious way that a customer can determine what, if any, security standards a merchant might have implemented.
as mentioned in the various previous references ... what is at risk ... effectively proportional to the aggregate of the account credit limits ... for all accounts that happened to have been stored in any account master file ... is significantly larger than any particular merchant may have directly at risk because of a security breach. in the "security proportional to risk" theory .... the entity that has the risk should have control over the security measures, those security measures should be proportional to what they have at risk, and the cost of those security measures should also be proportional to the risk. A complex, multi-system internet web implementation may represent a significantly greater cost than the direct busines value a merchant may be doing on the internet (not to mention the cost of the care and feeding of such an implementation). I would claim that any impression that such an implementation is required is proof that what is at risk (value represented by the account master file) is not directly related to what any merchant might have at risk with putting up a merchant web server. Furthermore, I would claim that it would be possible to find account master files (regardless of the volume of a merchant's internet business) that represents a risk level higher than the merchant direct risk ... and therefor there will always be merchants (at all business size segments) that find it difficult to provide security proportional to that risk. This is simply bad design - there should be no "account number master file" on the web server! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]