Would you like to see your name, address, birth date and email on a public bill board? On the main street? What if the bill board is behind a big sign “don’t read this”?
If that worries you, why do you give your data to web sites of big companies? Many of them, even the big ones, show very little interest in keeping your contact detains secure. Many sites are still vulnerable to cross site scripting or SQL injections.
If anyone puts your life or privacy at risk, they are liable – except when web sites are involved. Even if they violate common sense and even the most basic rules of security, the worst that can happen is that they have to apologize. Pollute some fish? To Jail! Lose 300 million customer records? Oops, sorry about that.
Paul Venezia asked an interesting question: Should companies be accountable for the security risks they take? He says:
In the United States, at least, very specific laws govern patient information and how it is stored, accessed, and disseminated. HIPAA regulations were put into place to ensure that sensitive patient information isn’t distributed to just anyone — that is, only to the people who need that information. They also prevent health care providers from discussing any type of patient information with anyone else. They were explicitly designed to protect patients, and each patient must sign a waiver to authorize the release of that information to another person or party. Yet we have no regulations on the storage, access, and dissemination of sensitive user information on public websites — none. Thus, there’s almost no business case for providing any form of high-level security for customer accounts.
Interesting thought. I have two comments:
1. Not individual developers should be liable but the company which runs the site. It should be in their best interest to keep their data secure.
2. Today, it’s too complex to create secure web sites. Yesterday, I used renderSnake to create some HTML. If you supply a string value for output, the default is not to escape HTML special characters like <, > and &.
Creating a login component for a web site is pretty complex business and there is a no reasonable tutorial or template component which you could use that gets most security issues right like:
- Transmitting the password via HTTPS (encrypted) instead of using plain text (which anyone in the same LAN can read)
- Encrypting the password before it’s stored in the database
- Storing the password with a salt to make it harder to attack it with rainbow tables
- Escaping special characters in user names and password to prevent cross site scripting or SQL injection.
- Avoiding security questions like “Name of your cat?” More than 50 people know the name of my cat! The name might even be on the web somewhere (possibly next to a photo on Flickr) How secure is that?
Dark Views 