mpkossen

I'm just guessing, but maybe the server is still spitting out e-mails to customers informing them about the stolen data. This could postpone the sending of password e-mails. Just be patient and cancel your credit cards.

Whoa, dude. It's everybody's own choice to submit credit card details here. I've always used PayPal for this reason. People hand out their credit card number to every site they visit without thinking twice. That's not completely WHMCS' fault. They should have had better security/encryption, but you could have also chosen the safe way.

Yes, or at least the support would have been decent and wouldn't have just given out details. I would *always* be suspicious if a customer would request details via non-standard channels. I'm not saying that's the case here, but it could be.

They've downloaded the entire cPanel account, so yes, the configuration.php is in there and yes, they can decrypt credit card numbers. Time to get it cancelled.

It won't be long before these files are available as a torrent or via newsgroups. It's hard to stop from there. Please note: I don't condone the release of these files or the spreading of them, I'm just saying what may very well happen.

First of all I'd like to wish Matt and the guys the best of luck during this hard time; irregardless of how it happened, it's never fun to have your business touched like this. About the situation: I have to assume that credit card details are stored encrypted, but decryptable. Otherwise recurring payments couldn't be made. You need the credit card details for that. Based on that assumption, I also have to assume that all credit card numbers will eventually be decrypted and possibly sold/used. So my advice is: cancel you credit card (and start paying with PayPal!). I'm unsure how passwords are stored, but if it's plain md5, most of them will be decryptable by now. If it's salted md5 or sha1 (salted or not), I'm seeing less trouble. I've already changed my password, though, just to make sure. About the hosting provider: I hope they're finished or at least hit hard by this. It's absolutely unacceptable for a hosting company to let this happen. It is *always* fishy if an administrator cannot find their details and can't recover them from the client area. It's even more suspicious if shortly after giving access, the e-mail address is changed and the login details sent. Hosting companies should be so much more careful with this. Finally, I'd like to keep getting updates on this. Clear customer communication is extremely important in cases like this. So I really hope the current way of communication is set forth or even improved (more details!).

That's quite new to me, thanks. I'll have a look and see if that has the desired result.

Are you sure? Because there's not way to set the next invoice number if not using sequential paid invoice numbering (that I know of). Besides, there's no way to prefix it or even control the format (again, that I know of). I think WHMCS adds an actual invoice number (other than the ID) only when it has been paid, and uses the ID before that. The problem with proforma invoices is that they are not legally valid invoices. With only a proforma invoice, I would never be able to force a client to pay unless I have an actual invoice (which is only being made after I mark the proforma invoice as paid). That's why I cannot use proforma invoices (without risks).

I think that's not his issue, John. I think he has the same issue I have. Sequential invoice numbering currently means having to send a Proforma invoice and a final one. It would be much simpler if the invoice numbers would just be assigned sequentially when the invoice is being created and kept at that. The customer then receives the invoice when you create it and can use that copy as the final invoice. The payment confirmation is than just that, and not a final invoice. Currently, you have to explain to people what a proforma invoice means and how it works. This prevents me from using the invoicing part of WHMCS, because customers simply don't understand why this procedure is needed.

(Sorry, cannot edit/update my previous post) I've been unable to find the cause of the issue as it's hard to debug with the code that performs the call being encoded. This could probably be filed as a bug report since it's something that should work that doesn't for various people (who use 100% confirmed working details).

This puzzles me as well. I'm currently investigating. I hope to find out what happens soon.

Thanks for the fix!

OK, thanks. Any plans to support sha1 in the future?

I've removed it from the templates already. Thanks for the tip, though I'm really sorry, I've just noticed that MD5-passwords can only be disabled via the admin area and that it resets all passwords. Would the template field have worked with MD5-encrypted passwords? Or would it have been empty?

It occured to me what WHMCS sends passwords to people. Not only is this a security risk in itself, it also means that passwords in the database are not secure in a sense that they can be decoded back to a normal password (a sha1-encoded password virtually cannot be decoded) even though they are encrypted in the database. I'm wondering why WHMCS sends passwords and why then can be decoded?