Dieter Vanden Eynde

0-byte bugfix for perl blowfish package

Mon, 24 May 2010 14:50 +0100

I found a small bug in the blowfish package I published a while back, more specifically in the decrypting method. Blowfish works with a block size of 8 bytes (64 bits), if the package does not have enough bytes to fill 8 bytes it will fill the missing bytes with 0-bytes. In a ASCII context 8 bytes means 8 characters, meaning the any string length that cannot be divided by 8 will have 0-bytes as suffix. When outputting the decrypted string you will not see anything wrong but when doing checks (regular expressions for example) you will get incorrect results.

The new version fixes this 0-byte bug.

Download: Blowfish_v1_0_1.pm.zip (1,6K)

Using blowfish on IRC via perl

Thu, 25 Feb 2010 19:39 +0100

Security is a big issue nowadays and if you are a frequent IRC user like me, its not always easy to chat securely. Luckily most servers support SSL connections but not all. For the ones that don’t support it or for the people that are completely paranoid there is another way to encrypt your communication which is the blowfish algorithm. This algorithm will encrypt your data using a secret key. A second party can decrypt it using the same secret key. For IRC there is a plugin called fish which can be used by several IRC clients.

My problem was that my IRC bot didn’t support blowfish so it couldn’t be used in encrypted channels. There isn’t a straight forward package in Perl (my bot is written in perl) for encrypting/decrypting blowfish on IRC so I had to fabricate one. The package is available below.

Usage:

    # package
    use Blowfish;
    
    # encrypt
    my $encrypted = Blowfish::encrypt('this is plaintext', 'secret_key');
    
    # decrypt
    my $decrypted = Blowfish::decrypt($encrypted, 'secret_key');

    # prints 'hwwnV0UVbDE1z2N0E0AZlBT/Mi965/OLpHf/'
    print $encrypted ."\n";
    
    # prints 'this is plaintext'
    print $decrypted ."\n";

    # send to irc channel
    print $ircSocket 'PRIVMSG #channel :+OK'. $encrypted;

Update: Fixed a bug when decrypting, more details
Download: Blowfish_v1_0_1.pm.zip (1,6K)

Suggestions and feedback are more then welcome!

Reading and writing simultaneously on a socket in Perl

Sat, 23 Jan 2010 20:46 +0100

If you want to read and write simultaneously on a socket in Perl you have to set the socket to non-blocking mode. A socket is by default exclusive to reading OR writing. This means you can not write to a socket while you are reading from it.

IO::Socket::INET has a parameter “blocking” which should handle this but that didn’t work for me. However the search engine concept proved its purpose again and the following saved me:

# Create socket
my $sock = new IO::Socket::INET(PeerAddr    => 'localhost',
                                PeerPort    => '8080',
                                Proto       => 'tcp') or
                                    die "Can't connect to server: $!";

# Nonblocking mode
my $nonBlocking = 1;
ioctl($sock, 0x8004667e, \$nonBlocking);

# Read and write
...

Create your socket and after that use the ioctl function to manipulate it. Important is that you pass the variable by reference. Setting the argument directly or without reference does not work.

Salting passwords

Tue, 01 Dec 2009 14:50 +0100

I wrote an article about this a few years ago but since I don’t have a backup of old articles I might aswel write a new version with new information. To get started: What is salting passwords? Wikipedia has a detailed explanation for it but in short it means adding a prefix/suffix to your user passwords making them more complex without forcing users to use complexer passwords.

Example

User A has a password “hello”. This is a very simple password, a cracker/hacker/bot would crack it in a hartbeat. Why? Because it is only 5 characters short and it is a common word.

password: hello
md5: 5d41402abc4b2a76b9719d911017c592
cracktime: 0.023 seconds

As a developer you have the amazing power to make this more complex by adding a prefix or suffix to the password:

<?php
$password = 'hello';
$salt = 'EgO8LQhvFBNN';

// truncaten salt and password and creating a md5 hash
$aUser['password'] = md5($salt.$password);

# new userpassword: EgO8LQhvFBNNhello
# new password hash: af82d9692551c4d21d522e9cc81e8dee
?>

This makes the password hash more complex and it will take a lot more time to crack. But with the hardware getting faster and faster we need to take extra precautions by hashing the salt and password individually first:

// truncaten salt and password and creating a md5 hash
$aUser['password'] = md5(md5($salt) . md5($password));

You can choose to have a general salt for every user on your website but you could also choose to give every user a different salt. And you could change this user salt every time he log’s in. This would result in a password hash that changes after every login making it much harder for crackers to use dictionary attacks.

I can hear you thinking, what if the cracker gets his hands on the salts? All these precautions would be for nothing. Wrong. Hashing a password is a mathematical calculation, which takes time. The more times you hash a password or salt the longer it will take to crack it. If you use a unique salt per user, a cracker has to recalculate the salt hash for every user. Instead of calculating it once and comparing it with all the other users.

You can’t stop a password from being cracked, you can only delay it.