tech question - ccbill + our own user auth system
 

Hi folks,

First post here so Ill say hello to one and all first :-)

Ive had a look around the forums and see there are a few members who are actually involved with ccbill and some that run sites of a similar setup.

Now on to my question ...

We're developers with experience in building member sites for other industries but not adult sites. Normally we manage all the user authentication system so that users can sign up , log in etc and then take part in all the interactive elements of a site such as forums, blog comments, choosing favourite items etc. Once a user logs in via our auth system we can then obviously track the session and users id etc. Knowing when the user is logged in and thus who they are we can control everything we need to with a little coding.

So, the problem

Weve signed up with ccbill to manage the subscriptions and affiliate system and can see that most sites work on the basis of a tour and then put all the members content in a subdomain or members folder etc and then use htpassword to control access. The problem is that apart from using a users IP address there is no way of knowing who the user is once they have passed the htpassword popup.

How do those of you who use ccbill to protect your members only content also track who those users are once logged in.

If you have a forum setup for members do you then require the user to sign in again to your forum system after they have logged into your members area ?

Hopefully you understand what Im talking about here. Im sure many of you allow members to add comments to sets or chat in a members forum.

One option I guess is that we allow users to sign up as a free member and allow comments to the blog etc and access a few downloads but then require they upgrade their account by paying via ccbill and use the post back functions there to upgrade their account giving them access to everything else. In this case though we would need some sort of api to access data at ccbill to check each time they login if they still have an active account with us at ccbill.

Another thing I have noticed when reading other posts is talk of password sharing and the use of "strongbox" . Could someone give us some info on the type of hacks and cheats used to scam access to members content. In other sites (non adult) we track every user download and so know if any one user is trying to download the same file too many times in any set amount of time which would lead you to believe that its not one user but many users all using the same id.

Would very much appreciate some advice on what the tried and tested methods are and their advantages or disadvantages from those of you with more experience in this industry then us.

In a nutshell the question is how to best implement a paysite system using ccbill but with as much user interaction and members features rather then just a static site with a standard tour out front and all member content locked behind htpassword logins.

Look forward to hearing your views and getting to know you all

Strongbox can do what you are asking for.

the server variable REMOTE_USER can be used within your system to get the username that was used to sign in when using .htaccess authentication. CCBill does support writing to a mysql username/password.

Strongbox prevents password trading by inserting its own authentication method using mod_rewrite, but, reads the .htpasswd file (or mysql database) so that it knows what usernames are allowed. Password hackers will run dictionary attacks against members sites that they want to get into (200,000+ user/password combinations they have grabbed over the years), so, if you write your own authentication handler, be prepared to have a lot of proxy servers knocking on the door. Strongbox also puts in captcha (if desired) and a number of other things to prevent automated surfing/login.

The simple answer in your case would be to adapt your existing system to read the .htpasswd file (or mysql table) for the authentication and use the same internal methods that you have used on all of your other sites. No sense reinventing the wheel.

If I'm understanding the question right he is asking if there is a way to give access to other protected areas after the member has logged into the primary member's area and that is something that Strongbox does very nicely using a bit of handoff code.

This type of system, built robustly enough for a popular adult site, is
not something you're going to whip up real quick after getting a couple
of ideas from some webmasters, who are people in the marketing
business. This has been our business for twelve years, developing
effective protection. Over those twelve years we've put over a THOUSAND
hours into research and development and we STILL have a very long
TODO list. Our biometrics seem to work pretty well, now on to some
other needed improvements to stay ahead of the hackers. It also
sounds like you're not familiar with basic server variables like
REMOTE_USER, so you're definitely looking at some schooling before
you get into the development. My suggestion - you develop whatever
members' area CMS features you do a good job with, make something
new that's really neat, and leave the security to the people who do
security 24 / 7 / 365. We'd love to work with you and we can
build in some cross-compatibility where your members' area
content stuff can work with our security stuff, but please, "security"
mechanisms developed by those who have no background in
security or understanding of the principles of web security are flat
out DANGEROUS. We've seen far too many login systems that a
hacker can use to dump the whole user database. Actually this
board is an example - it's a great message board, the script is
made by some people who really know how to make a great message
board. However, as I demonstrated on Netpond, the authentication
is wide open. All that I have to do in order to get full admin access is
make a post. When the admin reads my post, I have their password.
Great software, vBulletin, but they aren't security experts so they
don't know how to do authentication right (nor should they know, that's
OUR job, and we don't need to know how to build message boards).