And I thought sfDoctrineGuardPlugin was bad…

Update: You can safely ignore this angry rant as the issues have been fixed.

I am speechless. While doAuthPlugin looks interesting (especially because it uses inheritance and not some silly secondary Profile table), on the topic of security it is worse than sfDoctrineGuardPlugin.

Let’s have a quick look at doAuthTools.

  public static function rememberHash(User $user) {
    return md5($user->getId().'-'.$user->getUsername().substr($user->getPassword(),0,5));
  }

There’s the use of md5, which doesn’t doesn’t resist long to rainbow tables attacks nowadays, but the worst is what is used. No random data at all, no salt.
The user id is most of the time public, the username almost always is, and for absolutely no reason only the first five characters of the password are used.

  public static function activationCode(User $user) {
    return md5($user->getCreatedAt().time().$user->getUsername().substr($user->getUsername(),0,5));
  }

created_at is easy to guess, time() is easy to guess and the rest is public. Again, what’s with the use of substr()? I would also guess the author wanted to use the password and not the username.

  public static function generatePassword() {
    return substr(md5(rand(1000,9999).time()),0,8);
  }

Now this is just sad. Sure, even with the use of a-f0-9 there is still 16^8 possible passwords, but why not spend a little time and try to use all the available letters? It also means that if you know the user id and username, you know you only have 16^5 rememberHashes to brute-force, which is easily doable.

We’ve already seen that using rand() is bad, but restricting it is even worse. Why on earth? To sum up, the password is constructed from a poor random algorithm with under 9000 possible values, and an easily predictable timestamp.

Frightening.