I think you'd want Digest::MD5 instead, which doesn't take a key.

MD5 is a cryptographically secure one-way hash function. That means that given some bits as input, it will output some bits that could only have been generated by that input, and it won't be possible to calculate the input by looking at only the output, at least not given less than a few years to calculate.

The scheme you've proposed is a challenge-response system. It's a fairly standard way of doing this sort of thing, and it's a secure way to do it. The disadvantage is that both sides have to know the plaintext password (as compared to, for example, the server only knowing a hash of the password, like in the /etc/passwd file). It's important to make sure that at least part of the string is truly random, and that it never repeats. You can use Math::TrulyRandom to seed rand, and combine that with the time and PID, to accomplish this:

use Math::TrulyRandom;
my $seed = truly_random_value();
srand($seed);
my $randbytes = join("",map {int(rand(10))} (0..16));
my $challenge = join(".",time,$$,$randbytes);
[download]

The way to use the scheme you propose would be to send the challenge string, then the client concatenates the string and the password and takes an MD5 hash:

use Digest::MD5 qw(md5_base64);
$digest = md5_base64($challenge.$password);
[download]

then send this to the server. The server also knows the secret and the password, so it can do the same calculation, and make sure that the hash sent by the client is correct. Since MD5 is a cryptographically secure hash, it's safe to assume that the only way the client could have calculated this hash is by knowing the password, so they're authenticated.

The big disadvantage of this technique is having to store the plaintext password on the server. Because of this, I nearly always use SSL instead of a challenge-response technique.