> if i as a bank, refuse to allow you to signin to my server, because i > detect > that your client is not valid/legitimate, meaning i think it's been > hacked, > how have i trampled the rights of anyone. i haven't. will some customers > run, sure.. perhaps.. will i potentially feel better. yeah. will i > potentially have something that i can promote as an extra level of > security > that others don't have, maybe.. The banking industry is generally not slow in exploring security issues. In point of fact, I know a guy here in Australia who works as a consultant for the major banks on encryption protocols and strategies (and his encryption-related background before working privately for the banking industry is *scary*), so it should be a given that banks do care about security both generally and specifically. That having been said, you're waving the stick around by the wrong end. It is fundamentally more important to a bank that general access to customer records be protected, not to specific records relating to any one customer because of that customer's negligence. By this I mean, most of their money is invested in attempting to stop hostile attempts to gain access to customer databases at their end, not at stopping hostile attempts to gain access to customer data at the client's end. Why? Because that's where the liability lies. Follow the money. If you expose your own records by being foolish enough to run spyware-ridden browser software, this is your own issue. Again, as I mentioned before, once the data is in your hands, it's your responsibility. Behave responsibly or stupidly / ignorantly, the choice is ultimately yours. > let people continue to read/hear about massive losses of data and see what > happens... Again, the massive losses of data we generally hear about are not as a result of sniffer programs sitting at the client end. They're ordinarily about hackers gaining access to the data at the source, where thousands or millions of customer records can be compromised, not at the client. This doesn't mean it's not an issue, but that it's an issue that can't and won't be addressed by anything more than public awareness campaigns. Which is why I think you're wasting energy on this topic. I'd much rather see you or anyone else, for that matter, putting this care and attention into reviewing how secure your app is, even if it's for the 20th time, than wondering how you go about hypothetically doing something that can't be done, and which, to the best of anyone's knowledge, isn't going to be practically implemented by anyone any time soon. Obligatory, "Oh my god, can you really believe they did that?" story: >From a consultancy project I was hired on to extend a retail web site. SSL encryption where customer data was being entered or viewed? Check. Efforts to negate the potential of SQL / code injection? Check. Backup strategy? Daily dump of all records using PHPMyAdmin. From a directory where SSL was not being enforced. All that customer data. All that effort to protect it from being exposed to hostile eyes. From a directory where SSL was not being enforced. Makes you want to weep. Regards, Murray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
