PHPBuilder - Security versus user friendly.



RSS Twitter
News Application Architecture

Security versus user friendly.

by: Aivaras Voveris
|
November 3, 2009

One of the core part of a qualitatively website is its security. There are lots of sub-categories in security and I am only going to cover one of them.

So you have this new project and a request to pay seriously a lot attention to making it user-friendly (accessibility issues, etc.)

While you are designing application in your mind and thinking about this superb idea to make the website more user friendly, a colleague of yours (usually the one which is not that much into computers) asks to check out her laptop, because the password simply do not works, even though she is 100% sure that the password is correct.

What you actually do is come to her laptop, take a look at flashy little lights somewhere next to keyboard, then smile and click caps-lock button. She looks at you with those eyes telling that she treats you like an extraordinary computer expert.

The story is great, but how is it related to security and user-friendly application? Disable the need of case sensitivity. If this sounds crazy keep on reading, if not, I hope that at least a story about a caps-lock lady was interesting.

How to achieve this? Oh, just use strtolower(); before actually hashing the password. Experts would probably laugh a lot, but lets explore this idea deeper.

Say that John has the following password: BritneyRocks58 So this password's strength is somewhere between low and medium. This password has uppercase, lower case letters and digits, which make it quite cool, because of the use of 3 different location areas in ASCII table meaning a brute force attack (if password's hash is exposed) a longer process. However, the password is based on words from dictionary and makes cracking the password an easier task. Looks like this whole analysis is telling that switching all uppercase letters to lowercase is actually a bad idea. It's not, or - that depends. When password is converted to lowercase characters, we only increase the probability to type the password you have just seen your friend typing and if that is the case, security is nothing to do with this.

Give us some salt! System operators are frequently telling their colleagues at work that password looking similar to "hfu213giuhXI" is just prefect.

That is where the salt comes in. What if we add a string like this "fhshp';$ %^)(AV_something_random_more" and only then hash the password for verification? Simple, we can forget about application users' getting caught into caps-lock issues. Password's strength is high now, because we have some user inputted characters and our salt, making the range of character groups in ASCII table very wide. Even sysops have weaker passwords then a-zA-Z0-9\s and special characters. By the day when I am writing this article, brute-forcing user's password would take longer then the user's information's value would fade away.

Function to do the task for you:

function hashString($sString = ''){
	$sHash = strtolower($sString);
	$sHash = sha1($sString);
	$sHash .= 'Your own set of random characters here';

	//hashing one more time, makes the eta field in bruteforcer go even more wilder, but consumes more server resources
	$sHash = md5($sHash);
	return $sHash;
}

Happy coding,
Aivaras Voveris
Student

Comment and Contribute

Your comment has been submitted and is pending approval.

Author:
Aivaras Voveris

Comment:



Comment:

(Maximum characters: 1200). You have characters left.