I don't think it's a 5-6 day thing, I have manual added logins that have been working for a long time after expiry. That's why I was worried subscriptions would do the same thing, that's why I knew right away. I couldn't show ccbill the manual adds still working because there is no report to show expired manual adds. So I waited until first subscription ended and took it to support.

And regardless of it's been discussed before, I would have made the thread anyway because I don't see CCBill telling anybody, so I am sure it needs to continue being brought to peoples attention.

Actually I am using password sentry, not strongbox, i just figured more people knew strongbox. Pretty much same thing? Im actually not familiar with strongbox.

And yeah it was confirmed that they were supposed to expire last night at 11:59.

That would be a great solution.

Speaking of manual adds.... another disturbing observation for us recently was we discovered a pass sharing site about 2 weeks ago but what was bizarre about this password post was this...

We had manually added 3 logins and pass for close trusted friends. All 3 of The manually added logins were posted on the forum. We did not notice other logins posted on this particular password forum.

But the 3 exact manually added logins within the past year were posted.

So is it safe to assume that our manually added logins are compromised/hacked not secure? Can anyone make sense of that?

I am not sure what you mean by bad ccbill sales reports. We are currently investigating an issue we had with our quick stats overnight. However, to my knowledge all of the other reports are and have been functioning properly.

The problem described here by the OP and others is simply with our systems ability to remove usernames and passwords from the password file located on the clients servers. For example, customer John Doe is due to expire and be removed from the password file on the 23rd. Our billing system knows this and when the 23rd hits our system sends a remove command to our user management script located on the clients server. There are numerous reasons why we are not able to remove a user and our teams are working on resolving these once and for all but I can assure you the reports and the removal of the users from the password file are two separate systems. We always know when the user is to be added or removed but we are not always able to perform that function.

Back in the old days, hackers would hack the ccbill file. I thought this was taken care of, but yes, I use to find my entire user/pass lists on boards.

NO it was not my server hacked, I did extensive research on how people would crack the ccbill files. I have not heard about it in a long time, so I figured it was over.

Paul you are a great guy, and about the only one to get issues figured out. THANKS!

CCBILL rarely has a problem ADDING members, yes emails are sent that you could not. Never, have I had an Email saying you could not remove a user. I understand money wise the focus is on the sale and getting the member happy and able to login, so that would make sense that user removes are put on the back burner, or only ONE attempt made.

I bet the percent of users not removed is fairly small compared to the number of total joins ccbill does daily. Today with it harder to turn a $, this has become an important issue with webmasters who know this is happening.

No bashing on CCBILL this time, as we all know errors happen, just hope to have a little more effort in a clean up process!

It happens/has happened to us also, however, you can request the password files for all subaccounts on a month to month basis; that's what I do.

I know it's not a valid solution since it's CCBill's system NOT doing its job, but I think it's wise to be doing maintenance on your password lists anyway :2 cents::2 cents:

What I meant is that the problem isn't new, and isn't just yours. They've had this issue for YEARS. That said, one could argue that it's really the Webmaster's responsibility to oversee the integrity and accuracy of data on our servers. That's reasonable, but it's also reasonable for CCBill to say that -- under certain and unknown conditions -- it might be necessary.

You can track what their script tried to do by looking into the ccbill transaction and error log. Both are tucked in the cgi-bin folder with the CCBill user management script. Simply fetching and reading this file offline won't interfere with anything.

You mention manual adds, and using Strongbox. I take it the manual adds are in the CCBill admin, and not being made in Strongbox. Obviously, CCBill has no knowledge of users you add or remove via the Strongbox control panel.

Long ago I set up a couple of Word macros that strips off all but the username in the htpasswd file, and sorts it. It's a macro you can record, and isn't complicated. You can then download a member list from CCBill. Include only usernames. Now do a document compare between the two. You'll instantly see any usernames that shouldn't be there.

If you have more than one biller you'll need to combine the active username lists from all of them. Last time this came up Ray of Strongbox indicated he created a script within Strongbox to do all this. I don't know if it's something that costs extra, or what, but you may want to ask him about it.

yeah but I'll bet your retention ratios are jammin'

Fitty expired logins:disgust

What they did was find the CCBill log file, which contained usernames but no passwords. They'd then compare those usernames against a list of previously cracked u/p pairs, for a more effective brute force attack. This shouldn't be happening now if your site was set up properly.

Hackers can still get your htpasswd file, which can be located anywhere. It's important that it located above the document root, and that you have no scripts running anywhere on your site that can return arbitrary files. Best to put the htpasswd file in an unusual location, and name it something unique. Consider using a stronger encryption on your htpasswd file, and to require customers to use passwords at least nine characters long (or provide them random usernames and passwords - but not the insanely unusable ones CCBill offers; use the passgen utility that Strongbox offers).

If you get confirmation emails be sure your email is secure. If your email account has been hacked they can look at all the confirmations, which by default have the username and password in them.

This is what everyone should be doing. Create your own database and don't rely on ccbills member file. Automatically terminate your members account on expiration and only renew it if CCBill writes to file with successful rebills.

The problem is not just rehauling your membership file each month but TOTALLY creates an inconvenience if you use any other billers, which, of course, you should be.

make sure your .htpasswd file permission is set to 666

i was having the exact same issue and each month i would have at least 50 extra members in my htpasswd file. it's hard to sell memberships when they're free...

at beginning of each month i ask for a new htpasswd file and compare it to what's on my server.

I also had this problem. Issue went on for months before it was caught. Of course it lowers sales... the people that paid for the site are the ones who will pay again. It is an issue of financially gargantuan losses :(

Hey I am still learning something new everyday.... regarding the htpassword file I was always under the impression it belonged somewhere in the ccbill folder or directory.

Today after reading this thread discovered that the htpassword file is located inside of members area? WOuld you consider this a standard/secure place for the file to be located.

Seems like its been there for almost a year now. Hope its not a dumb question

Your .htaccess file, to control access to that directory, is in your members area. The .htpasswd file, which contains the username:password pairs, as a precaution belongs outside any place where the Web server can get to it. For example:

Scripts can manage files outside the document root, but Apache (or other Web server software) can't serve files from there. It can only directly access files under public_html.

You have to make sure you have no badly written scripts that can serve up arbitrary files. For example, having some PHP script in a page that can display just any file on your server is a bad thing. Some poorly written Pic-Of-The-Week scripts were like this.

I see the difference now thanks for the clarity:)

You should take a peak at your ccbill log file that the cgi file writes to. If there is a REMOVE log entry for a username that is still in your htpasswd file then something is wrong with your cgi file / server settings. If there is no REMOVE entry for a username that expired, it could very well be a temporary routing issue where CCBill couldn't load the cgi file to remove the account. Have you had any server outages lately that could be related? But yah you should have your password files rebuilt every so often to make sure you are not giving away to many freebies.