I haven’t really checked back recently since writing my posts on unsafe poker rooms that fail to encrypt your personal information but Brian over at MattahFahtu did take the time to check ’em out and it looks like they’ve finally gotten around to correcting the problem.
I guess what really cooks my goose on this is that someone made a conscious decision to do this. This isn’t a case where you have two distinct pieces of software for .Net and .Com. Here was a piece of software that encrypted your password if you had a real money account and left your password completely exposed if you hadn’t made a deposit yet. In other words, you had code that looked something like this:
if(realmoney) {
encrypt_and_store();
} else {
just_store();
}
What possible purpose would there be in not encrypting the password? You had to go out of your way not to do it! In fact, if you later deposited funds, the software would presumably have to go and encrypt your password so not only did you have to go out of your way to write the unencrypted password but you had to write even more code that went and encrypted the password once a deposit was made.
Given the above, I’m going to guess this wasn’t just some rouge programmer who got lazy*. Instead, I’ve got to believe that some product manager spec’d it that way. For what goal I have no idea.
* There is one scenario where an incompetent programmer might have done this. It would be if that was his flag for whether an account was real or play money. There are at least 100 easier ways to flag that information but it is possible that is what the unencrypted value was being used for.