Can you trust a web-form?
Can you remember the last web-form you completed on a web site? Can you remember what you entered? My guess is that it was at least a username or email address and a password. Now imagine what a malicious user who “listened in” to your input could access. The odds are that you used the same password as most other sites you visit, just to get it done. So you’ve just compromised not only the site you logged in or registered with, but just about any account you have online. If I was a hacker, I’d start expanding my attack to big players, like Facebook, Twitter and maybe a few banking sites, just for a laugh.
Everytime you complete a web-form on a web site, you are placing a lot of trust in the various parties involved in that connection to the internet, and you won’t know about all of them. Consider the following parties involved in your web-form submission:
Your own computer: When was the last time you did a virus/mal-ware check, and with up-to-date definitions? Viruses are no longer bits of code that produce cutesy messages and graphical effects, they are silent, subversive and distributed. If you have a virus that logs your keystrokes, it could be sending every keystroke to computers all over the world. Your secure connection and password is now useless as basic pattern matching can reveal you just entered your email address and password on a particular web-site.
Between you and the web-site: When a relative reacted with surprise that her emails were not secure, I realised that if you are not internet-savvy, users will approximate their interaction with services and users on the ‘net as the closest thing they have experience to - a telephone call, or a letter. Between your email client or web browser and the recipient or web site is an essentially infinite number of connections consisting of cables, routers, switches, servers and firewalls none of which can be trusted. Each and everyone of these can look at your submission and store it for later use. Of course, no ISP or internet routing agent would do this - knowingly - would they?. That’s why HTTPS was developed, which creates a secure, encrypted and certificated connection between parties. But HTTPS only works if you have sufficient trust in the issuer of the certificate, the certificate is itself valid, the submission of data is also encrypted (your URL may say “https”, but your submission may go in “plain-text”, using “http”). Which one of us checks all this before sending our data?
The web site: While you may like to think we only go to reputable web-sites, there are times when we stray off the well-trodden path to buy that unique gift, sign up for that cool service, etc. When you submit details to a web-site, you are placing trust in that site to capture that information and securely store it. We like to think that our submission goes straight into the database, never to be seen again except electronically when we need it - but what guarantee have you? Without looking at the source-code of the web-site, which would challenge even the most technical of users, you would never know if they were harvesting passwords, credit card numbers, selling email addresses, etc. And what if some malicious software has infected the site itself?
The authorities: The digital revolution is occurring very fast, and faster than the authorities can keep up. Public authorities, whether executive, law-enforcing or intelligence-gathering all have a degree of inertia as they are always playing “catch up”. This results in rapidly developed legislation, which is not always well thought through. Consider the Regulation of Investigatory Powers (RIP) Act 2000, or the Digital Economy Bill currently rushing at light speed through parliament as I type so it completes before the General Election. Such legislation is often rushed at the cost of adequate and fair consultation and implementation. Your data is subject to searching, retrieval and submission by your ISP and nominated public authorities.
As a company specialising in quality web-sites, we are aware of issues such as security and trust when users enter data in web-forms. While it isn’t possible to manage the entire communication (for example, we could never check your own computer remotely!) we will do what we can by adopting best practices in capturing your data and storing it securely. Recent projects we have worked on require highly sensitive information, which are central to the user’s identity and the viability of a business as an agent of trust. Therefore, it is essential that we implement everything we can to manage the risk of compromising of data.
Our approach starts with recommending clients who have a web-form which requests sensitive data (including username and password) purchase an HTTP/SSL certificate. This encrypts and signs the communication and acts as one layer of trust. When we store passwords, we store them in a hash, so they cannot be restored. So your password cannot be recovered even if the database was compromised. (This is why it can often be a pain to retrieve a forgotten password from some sites - they don’t know your password either, so need to prove your identity first before resetting it for you.) We employ best practices in anti-cracking to prevent or restrict the opportunity and effectiveness of techniques such as buffer overflow, cross-site scripting and cross-site request forgery. Finally, we recommend how the hosting infrastructure is implemented, so security is reflected physically. This involves splitting servers across firewalls to limit the possibility of a compromise and the extent of damage should it occur.
No web-site can be 100% secure. Working with user-submitted data is about managing risk, rather than preventing it. There are many techniques that can be adopted ranging from technical to the social. You might not realise it, but these tools are already in use at sites you regularly visit. Online banks use subtle techniques when asking for your memorable word to defeat key-loggers, web-sites use CAPTCHAs to prevent automated attacks and login forms don’t differentiate between “unknown username” and “unknown username and/or password” to avoid publicising that an account exists to try and crack. There is a toolkit of anti-cracking techniques, the strength of the professional is employing them tactically and effectively for the application.
