Password Encryption Using Salt

Now a day almost every application requires a log in. And we, as a developer has a big responsibility of keeping the user data secure. One of the many things which determine this is how we store the user password. We have been following a conventional way of encrypting the plain text password only using the general cryptographic hash functions like md5, sha1, etc…

Example:
md5($password)

One of the big disadvantages of this is, for same input we have same value of encrypted password.

To overcome this shortcoming we can use the salt along with the password for encrypting them. A salt is a set of random characters which is used as an additional input for hashing a password using a one way hashing function (Ex: md5).

Here is an example of how you can proceed with it:

1) First we will generate a salt which will be a sequence of random characters.

function create_salt() {
return substr(md5(uniqid(rand(), true)), 0, $salt_length);
}

2) Once we are done with generation of salt, we will use that salt to encrypt the password. This adds uniqueness as even for same password we will get different encrypted password as the salt will be different each time.

function hash_password($password, $salt = ”) {
if (empty($password)) {
return FALSE;
}
if((trim($salt) == ”) || (strlen($salt) != $salt_length)) {
$salt = create_salt();
}
return $salt . substr(hash(‘sha256′, $pwd.$salt), 0, -$salt_length); // whatever way you want to play.
}

Now let’s look at some of the advantages

Advantages:

1) It increases the complexity of password and thus has a very less chance of being guessed using rainbow tables approach. A rainbow table contains a list of already computed hashes. If a password is not hashed using salt then there is more chances of getting the plain text password using rainbow tables.

2) For same input of plain text password we have different encrypted password as we use unique random numbers as salt to encrypt the password thus making the encrypted password unique.

3) If somebody is trying to crack the passwords which is not encrypted using salt in that case they will have to guess once correctly and compare it to all the hashes. But if salt is used they will have to crack each password individually as each encrypted password is unique thus removing the possibility of accounts having same passwords being attacked at once.

Smile face program – PHP GD Function

Simple Smile Face Program Using PHP GD Library Function.

code:

<?php

header (‘Content-type:image/png’);

$c=imagecreate(500,500);

$bc=imagecolorallocate($c,200,100,100);
$fc=imagecolorallocate($c,225,225,150);
$lc=imagecolorallocate($c,20,20,20);

imagefilledellipse($c,250,250,400,400,$fc);
imagefilledellipse($c,150,150,50,50,$lc);
imagefilledellipse($c,350,150,50,50,$lc);

imageline($c,250,200,280,275,$lc);
imageline($c,250,275,280,275,$lc);

imagearc($c,250,300,250,150,0,180,$lc);

imagepng($c);

imagedestroy($c);

?>

 

The Best WordPress Security Plugin, Hands Down

If you’d like to secure your WordPress website without spending a great deal of time doing so, the best solution is to use one of the freely available WordPress security plugins.

There are quite a few options, but my security plugin of choice is Better WP Security.

I’ve installed and configured this WordPress security plugin on hundreds of WordPress installations, and I’ve never had a single WordPress property hacked with it on duty.

So, why do I like Better WP Security versus the rest?

For starters, it covers a lot of problem areas, and allows you to customize the settings for your particular needs. It also handles database backups, and will send you those backups via eMail attachments hourly, daily, weekly, or monthly.

I usually don’t enable all of the security settings, as some of the settings can be a little intrusive or bothersome. I don’t need all of them enabled to secure the website satisfactorily, but, they are there in the case that I decide to enable them for a particular site that needs a few extra layers of security.

The basic configuration I use covers the following points:

  • Your WordPress header is revealing as little information as possible.

  • Non-administrators cannot see available updates.

  • The admin user has been removed.

  • The user with id 1 has been removed.

  • Your table prefix is not wp_.

  • You have scheduled regular backups of your WordPress database.

  • You are blocking known bad hosts and agents with HackRepair.com’s blacklist..

  • Your login area is protected from brute force attacks.

  • Your .htaccess file is fully secured.

  • Your installation is actively blocking attackers trying to scan your site for vulnerabilities.

  • Your installation does not accept long URLs.

  • Better WP Security is allowed to write to wp-config.php and .htaccess.

  • wp-config.php and .htacess are not writeable.

  • Version information is obscured to all non admin users.

For me, this is enough. I can configure the settings quite quickly. At first, it would take me about half an hour to go through everything, but as I have become increasingly familiar with the installation and configuration process, I can usually knock this out in 10 to 15 minutes.

To give you an idea of the performance of this plugin and it’s settings, I once had a WordPress website owner contact me, telling me that his website had been hacked. When I visited his website, there were various “graffiti” present representing a particular “cyber army” which was claiming the blame for hacking his website.

He supplied me with access to his cPanel, and within about 10 minutes, I had regained access to the dashboard. I then went through all of the active theme files one by one, removing code added by the hackers.

Then, I installed Better WP Security, and configured it using the settings I normally use, without even activating any of the additional security settings, except for those listed above.

Within a couple of hours, I began receiving eMail notifications that someone was locked out of the site. Since the hackers were using proxies, I got quite a few of these notifications. I then went into the security dashboard, and permanently banned all of those proxy IP addresses manually.

Over the next few days, I got more notifications, and more notifications. The hackers were attempting to brute force their way into the website, however, they could not defeat Better WP Security.

In my opinion, unless you’ve installed a third party plugin that has security vulnerabilities, Better WP Security will keep your website hack proof, unless someone with a lot of time and computing power comes along, who also has great skill at hacking WordPress websites, and they are hell bent on getting in. Then, perhaps your site might get hacked. I would imagine that before it did, you’d probably receive enough alerts from the plugin to know that you had better contact your host, and let them know someone was attacking you, ensure you had up to date backups of everything, and perhaps enable a few more layers of security temporarily, until the hacker got tired of failure, and moved on.

I recommend Better WP Security to anyone running a WordPress website, it’s protection is excellent.

Should you need assistance in installing or configuring Better WP Security, I’m always around to lend a helping hand, via my WordPress Maintenance Service business linked in the navigation menu here on the Digi Purpose blog.

Jquery Ajax Cross-site error

This article is all about how to get jQuery AJAX cross-site calls working correctly. It assumes that you operate the server that the cross-site AJAX code is communicating to.

When configuring jQuert AJAX calls to work across different servers we kept getting the error “a is null” in the jQuery AJAX response. In particluar I was trying to get the AJAX call to work using XML as the communication method. After looking around online for a bit we found lots of cross site solutions ranging from using jquery json variations instead through to setting up some proxy code in PHP to grab the response for you.

These are overkill and there is a really simple solution. Just add this following line of code to the PHP file that the jQuery AJAX is trying to communicate to:
header(‘Access-Control-Allow-Origin: *’);

This simple line of code tells the server that it will allow cross-site communications to it… Which is what the AJAX will be trying to do. I’m not sure about the answer for ASP.NET servers but there is bound to be a similar solution.

WordPress pagination is not working

This post is all about how to fix wordpress pagination if it is not working, specifically that wordress pagination links redirect to the home page theme. A client of ours asked us to do some modifications on their wordpress website Without going into all the details, each category page follows a specific template and these templates need to support listing of content and pagination.

We did a lot of research into installed modules etc. and found that the reason that WordPress pagination was not working had to be something related to the wordpress core. We were able to alter pagination settings such as the number of posts per page, it was just the listing for page 2, 3, 4, etc that was the problem.

To give some background, we tried a lot of things to fix the WordPress pagination including: changing permalink structure from /%category%/%postname%/ to various other things; recreating the .htaccess file; altering the link structure in the wordpress loop; altering php snippets. Needless to say, none of these solutions worked.
Solution to wordpress pagination not working:

After some digging we were able to fix the wordpress pagination that was not working.

To fix this we left the permalink structure as “/%category%/%postname%/” and installed the Category Pagination Fix plugin. This works in our current version of WordPress 3.3.1. This plugin fixes when wordpress pagination isn’t working by using redirects when using a customer permalink structure that is more that 1 level deep.