Posts Tagged ‘Security’

When usability and security meet

Sunday, October 26th, 2008

Nearly always when your writing a website or web application usability and security clash – this clash is normally brought about by the client or designer insisting on specific features. As a Web Applications Developer and Linux administrator it is my opinion is that usability should never interfere with security.

Consider a basic login system, there are a lot of ways that a client or designers can request features that can interfere with the security of the system and sometimes no matter how hard you try to convince them that its a bad idea they still want the feature implemented. I’ve come up a list of frequently requested features from designers and a few solutions to try and keep both the programmer and designer happy.

Weak Password Policy

Many websites don’t seem to have any sort of password policy other than a one line statement stating that “the password must be 6 characters or more in length”. I cant emphasize how important it is to have a good password security policy. Brutus has made a name for itself as a web-based password cracker, it can run through a dictionary of words incredibly quickly. If you allow dictionary words to be used as a password then it should come no surprise when your system is compromised.

There’s not much you can do if a user or designer requests a weak password policy other than try to point out the reasons as to why its a bad idea. You could lock the users account after a specific number of failed attempts. Of course users wont be happy when their account is suspended and they cant log in

CAPTCHAs provide a solution which can prevent automated programs from guessing the password. There is no need to present the CAPTCHA straight away – after 4 or 5 failed attempts would be suitable. Its worth mentioning that many CAPTCHAs (including google’s) have been broken, though if they are designed correctly they will significantly increase the time needed for an attacker to carry out an attack. I’ll be posting soon about weak CAPTCHAs and methods for designing strong CAPTCHAs

Password reminders

When users forget their password some insist on being able to request a copy of their password via email. With the increase in password fatigue its more than likely that a user will use the same password for multiple websites. If your website gets breached and you store the password as plain text your website the breach could soon turn in to the least of your problems as other accounts belonging to the user become compromised.

Its best to store passwords as SHA1 hashes in the database, preferably with a unique salt for each password (this will help prevent rainbow table attacks). It means you cant request a password reminder, but you can always request a new password by email. The system can use this opportunity to set them a new password that compiles with the password policy.

It always worries me when I’m on the phone talking to a large company and they prompt me for my password – its a worry that I have to tell someone at the company my password and even more worrying when they suggest that I’m quite close.

Data leakage

Some websites kindly prompt you when you have entered an invalid and return a different message telling you when your password is invalid. Nice on the usability front for when the user forgets their username but horrible when it comes to security. It leaves a potential hacker the scope to guess the users who are registered with the system and then launch an attack on each one of those user accounts hoping to find an account with a weak password. Having a username reminder feature which works via email or even using the users email as their username helps to prevent the user forgetting their login details.

Conclusion

Usability and Security are clearly Orthogonal and you tread a fine line when trying to satisfy all the stakeholders. It continues to amaze me that designers and clients are still requesting that programmers forfeit security at the price of slightly better usability even when the consequences have been clearly explained. It amazes me more when programmers go ahead and implement their suggestions without confronting the other stakeholders about their security concerts. It might well keep someone happy in the short term, but in the long term its a disaster waiting to happen.