SECURE Billing app...?

I've been looking around the various billing solutions and you know one most of them all have in common? None of them seem to push the idea of how secure they are, or take security seriously.
Currently I'm looking to move to a more secure billing software, but I'm starting to think that perhaps its a futile search. Most of them have had silly mysql database injection vulns or remote code inclusion vulns in the past.
So my question here, is are there any solutions out there that take security seriously? By that I mean:
- have had their code audited by a third party company.
- don't store customer passwords in plain text in the database, only store a 1 way hash of them (it really isn't necessary to store plain text passwords for access to the billing app).
- customer details (address, names etc) are stored encrypted using a key not stored in the database.
- CC details are stored encrypted against a key made up from more than 1 system (i.e. half from another remote system).
Are there any solutions that tick any of these boxes? Ultimately I guess we need to code our own solution, but it'd be counter productive as we just don't have the time.
Discuss...

Try whmcs, or clientexec.
Aston

Yes very funny... Please, serious replies...

I would like to comment on a few of the points you made:
Quote:


- have had their code audited by a third party company.


Waste of time for any billing software author, as a 3rd party will have no existing knowledge of the system or functionality. They could miss blatant security holes, yet complain about false positives.
Quote:


- don't store customer passwords in plain text in the database, only store a 1 way hash of them (it really isn't necessary to store plain text passwords for access to the billing app).


Honestly, if a hacker is able to access the database (via any means), it is already game over for password security via hashing. They can just make up a new password, guess the routine used (usually md5) and hash it, and replace the old password with the new one. So hashing did squat for you there.
Quote:


- customer details (address, names etc) are stored encrypted using a key not stored in the database.


Not even possible, let alone practical. You would lose the ability to see any information about the client.
Quote:


- CC details are stored encrypted against a key made up from more than 1 system (i.e. half from another remote system).


I am intrigued by this idea. Please explain.





__________________LCWSoft - Canadian web hosting (based in Newfoundland)Uptime Report
lawrencewilliams (at) lcwsoft.com

Quote:



Originally Posted by larwilliams


Honestly, if a hacker is able to access the database (via any means), it is already game over for password security via hashing. They can just make up a new password, guess the routine used (usually md5) and hash it, and replace the old password with the new one. So hashing did squat for you there.


Agree with you there, but at least they wouldn't be able to discover the password scheme that the customer uses, i.e. they may use the same password for banking/services elsewhere. I don't see any reason why those passwords would need to be stored so they can be viewed. If the customer forgets his/her password then a simple reset is required. This wouldn't just protect the customer against unauthorised access, but also authorised access (i.e. company employees/contracters).
Quote:



Originally Posted by larwilliams


I am intrigued by this idea. Please explain.


Obviously CC details stored locally will be encrypted against a key stored on that system somewhere, if an attacker manages to compromise that system then they would have access to that key and thus those details. You could take this one step further and have half the key(or another key) stored on another system, which is where all CC functions (batching, cc updates etc) are run through and then passed on to the billing server for final run.
Quote:



Originally Posted by larwilliams


Not even possible, let alone practical. You would lose the ability to see any information about the client.


Hows that then? The key could be stored on the filesystem I was meant to say. It'd give you extra protection incase an SQL injection attack became about. Data would still be visible once logged in as admin/user.

Quote:



Originally Posted by Summy


Agree with you there, but at least they wouldn't be able to discover the password scheme that the customer uses, i.e. they may use the same password for banking/services elsewhere. I don't see any reason why those passwords would need to be stored so they can be viewed. If the customer forgets his/her password then a simple reset is required. This wouldn't just protect the customer against unauthorised access, but also authorised access (i.e. company employees/contracters).
Obviously CC details stored locally will be encrypted against a key stored on that system somewhere, if an attacker manages to compromise that system then they would have access to that key and thus those details. You could take this one step further and have half the key(or another key) stored on another system, which is where all CC functions (batching, cc updates etc) are run through and then passed on to the billing server for final run.
Hows that then? The key could be stored on the filesystem I was meant to say. It'd give you extra protection incase an SQL injection attack became about. Data would still be visible once logged in as admin/user.


Agreed on the password stuff, although I don't know why anyone in their right mind would use the same password for their important online banking site AND a hosting company, but I digress.
The only client data that should be stored is their name, e-mail and mailing address, and phone number. All of this is publicly available information, so it's not a major concern of sensitivity.
As for storing CC details, no billing system that is PCI compliant will do this. My understanding is that the CC must be encrypted in the billing system, except the last 4 digits AND the payment processor assigns an ID or something to authorize any future transactions. Correct me if I'm wrong.





__________________LCWSoft - Canadian web hosting (based in Newfoundland)Uptime Report
lawrencewilliams (at) lcwsoft.com

Why not design your own or hire a developer to code one for you? I know a lot of people would be willing to pay for a bulletproof system that cannot be comprimised, even though to my knowledge magic isn't real yet, wishful thinking is always a plus in my book.





__________________-Joe

Quote:



Originally Posted by Summy


Yes very funny... Please, serious replies...


You sound more funny to me..
Quote:



Originally Posted by ZKuJoe


Why not design your own or hire a developer to code one for you? I know a lot of people would be willing to pay for a bulletproof system that cannot be comprimised, even though to my knowledge magic isn't real yet, wishful thinking is always a plus in my book.


Second that. Since he is a 'funny' guy, I doubt the current popular ones will be of his choice.

I am currently using one of "the more popular ones". Granted, given enough time and other resources I think I would've written my own billing system, as the current ones sadly lack attention to security, e.g. storing actual passwords and not hashes, displaying passwords plain text in HTML forms, requiring PHP's register_globals, etc.
Not only that, some don't even have a decent database design! Lack of indices, constraints, incoherent table and column naming, and so on.
But they are popular and they work so far, and most importantly I don't have time to write my own, so...

Quote:



Originally Posted by davegaramond


I am currently using one of "the more popular ones". Granted, given enough time and other resources I think I would've written my own billing system, as the current ones sadly lack attention to security, e.g. storing actual passwords and not hashes, displaying passwords plain text in HTML forms, requiring PHP's register_globals, etc.
Not only that, some don't even have a decent database design! Lack of indices, constraints, incoherent table and column naming, and so on.
But they are popular and they work so far, and most importantly I don't have time to write my own, so...


1. NONE of the current products on the market are going to make you happy.
2. Hire someone and code it right. You obviously know what you want.





__________________TeamSpeakHost Inc. - Quality TeamSpeak ServersHostVentrilo - Quality Ventrilo Servers

Quote:



Originally Posted by Summy