Can we still trust the padlock?
The hot topic in IT news this week is the discovery of the so-called “Heartbleed” bug in the open source implementation of SSL, OpenSSL. This bug, which affects up to two thirds of all web servers on the Internet allows for malicious users to obtain the secret private keys used as part of the encryption process used to secure the data you enter on a form on its way to the web server for processing. And apparently, attempted attacks leave no traces of themselves behind. UPDATE: As usual, XKCD hits the nail on the head with their explanation.
IT admins world-wide are frantically patching their servers to close the security hole of a technology we are all so used to relying on – the little padlock in the corner of your browser that indicates it’s safe to enter your credit card number.
Whilst this bug is beyond catastrophic, it does only affects sites hosted on Linux/Unix server variants and not those running Microsoft IIS to serve their websites. Sites written in Microsoft .NET and hosted on Windows environments are not at risk.
The discovery of this bug raises the topic of security again in the public eye (it's public when my wife or mother email me asking 'should I worry about this?'), and may be concerning to those with their own websites. Whilst the threat of this bug will eventually pass, there are always basic security concepts to enforce when your website is being built.
Client-side security
Despite “Heartbleed”, SSL is still the best way to protect user data on its journey from browser to server. The exploit is not easy to perform, and does not affect all sites, so don’t think about launching a website that deals in sensitive data without buying and installing a trusted SSL certificate.
Developers should always ensure that absolute best practice is taken in regards to cross-site scripting (XSS) protection. Validate all your inputs – URL, form, cookies - server-side and assume that all user-inputted data is a threat.
Server-side security
Hashing of all stored user passwords so that they cannot be decrypted, even if obtained. Any requests for changing and forgotten passwords are via a confirmation email to a previously registered account.
Always follow PCI security standards for the storage – or lack thereof – of user payment card information. Store only the minimal amount of user information you require. Simply put: don’t even think about storing credit card numbers, even hashed. Let a secure payment gateway handle the burden.
Take payments on your website by a completely external entity, such as PayPal. This at least leaves liability with somebody else.
Consider abandoning local password storage entirely – allow access to your website only via Facebook, Google, Yahoo or other social media and other authentication platforms.
Pay a security firm to perform penetration testing against your website and server. You will be amazed what extra security holes can be closed simply.
User security
Train and prompt your users to change their passwords frequently. Demonstrate to them via screenshots what a legitimate secure page on your website looks like (particularly the URL in the address bar of the browser) and to look out for the padlock icon.
