If you are viewing this document in Notepad, please make sure to turn on Word Wrap under the Edit menu. Under Wordpad go to View>Options>Text and select wrap to window. Web site security has become a major issue for most web site owners, yet few people know how to really protect their web sites. Broken, cracked or stolen passwords can cause server slowdowns so dramatic that paying customers will get frustrated waiting for your server to respond with anything. With the large number of password sites on the web today, it doesn't take very long for a compromised password to get out to tens of thousands of people. If the right security precautions were taken, this wouldn't be a problem. However, most adult and subscription sites never take web security into consideration when they set up, and end up learning the hard way. If you currently own, or are considering starting, a subscription based web page, then you should be putting some thought into what platform (operating system) is going to run your web site. Something like Microsoft's Windows NT may look appealing, and is certainly easy to use, but lacks the security and performance benefits of Unix. My recommendation is to find a web server running Apache httpd. Apache offers a very reliable method of securing your website through the .htaccess file. If you are considering trying to use a Java based password system, stop! There is nothing I can do to help you there. The only real way to make a site secure is to get it onto a Unix type server, and use the .htaccess security model. Java based website protection can be so full of holes, I can't even begin to help you patch them. .htaccess ========= To protect a web site under Apache or other compatible webservers on a Unix platform is easy to do. There are two parts to this security model that need to be installed in your web. 1. The .htaccess file (check with your server admin-this file may have another name) 2. The password file Basically, any directory can be protected by a .htaccess file, and if it is, no one can browse that directory without supplying a valid name and password combination that exist in the password file. Not only that, but also all SUB directories off the protected directory are ALSO protected by the same .htaccess file, unless they contain ANOTHER .htaccess file. Confusing enough? Let's start by looking at what is in a .htaccess file sample .htaccess file --------------------- AuthName This is a private area AuthType Basic AuthUserFile /usr/home/bob/webpasswords require valid-user This is a basic .htaccess file. The first line, "AuthName" defines the words that are transmitted to the user's browser for authorization. You may have seen this pop up when attempting to enter a site...it is the line of text at the top of the window that prompts a user for their username and password. The AuthName can be anything, but it is recommended that you use a different AuthName for every different area you wish to protect, if the area has a different password file. This is because some web browsers read this line and save the username/password combination that the user last used for that AuthName. Think of the AuthName as being a phone number for the area, with the web browser spitting out the same username/password for any area with the same phone number. AuthType is basic. That's it right now, there is no other option-leave it. AuthUserFile is the filename of the password file for this web area. You can have multiple password files existing to protect different areas, but for most subscription sites, one suffices. This MUST include the full path to the password file, as in "/usr/home/bob/webpasswords" in the example above. The password file can be called anything you want, so this could be /usr/home/bob/mypasswords or /usr/home/bob/passwdstuff. The last entry in the .htaccess file is REQUIRED. In the example, we have set "require valid-user". This means that in order for someone to browse into the directory Bob has his .htaccess file in, they MUST have a username and password in the /usr/home/bob/webpasswords file. For most applications, this is the way to go, but this could also be set to "require bob", which would mean that out of the entire password file, the only valid password would be Bob's. And yes, there is an application for this, see "ADMIN SECTION" below. The second part of the protection formula is the actual password file itself, which looks something like this: bob:$1$Gp$q0hdQeqgvfrV8CFUTYZtuQ/ kesh:$1$Gp$jteGVwS7OOT36.kSP5tkXd1 john:$1$Gp$GnubNifvoqYtOw451xoaAj/ mark:$1$Gp$qeNG1K1wsYwENj1NXzWypH. brem:$1$Gp$.3m4f1akkSoXlh6HCn.9x. scott:$1$Gp$XYGxasC1PrauIfeL0pVH8. winter:$1$Gp$OYtwqHKWsKN7j1XUZsbqHa. This file contains the username and an encrypted version of the user's password. This version of the password is never converted back to a real word, every time a user logs in, the password they supply is encrypted with the crypt() library function, and compared to this password file. Even if someone out in the world manages to get this file, they will not be able to reverse engineer it, as the encryption is specific to the machine that the file is on. So once the file is taken to another machine, the real password required to make an encrypted version will be different. Very secure. So how do passwords and subscription sites get broken? Let's look at some of the ways, and what you as the website owner can do to prevent them. And The Different Ways that hackers Can Hack or Crack Adult Pay sites! TAKE NOTE: THIS IS ALL COMING FROM AN EXPERIENCED HACKER!!..NO JOKE! SO WE KNOW WHAT WE TALKING ABOUT!! The Different Ways to Hack/Crack Adult Pay sites!--POSSIBLE HACKS ============== 1. WEAK PASSWORDS This is a problem on so many Internet sites, and LOTS of email accounts. A weak password is something that can be guessed, mostly through brute force, by any hacker anywhere. Most weak passwords are the same as the user's login name. If you can guess a user login name, you can quite often guess that user's password. For Example The Most popular username/passwords are: 1) asdf/asdf 2) 123456/123456 3) fuck/me 4) qwerty 5) q1w2e3 6) zxcvb 7) abc123 And Also the most popular is the actual name of the Website! Ex: If the name of the Web site is : hotbabes.com Then try username : hot password : babes This method works alot! Basically, any easy sequence of keys on your keyboard like: 123321 zxcvbn abcdefg 0987654321 ..things like this are bound to work! How many times have we seen users named Mark using "mark" as their login name and "mark" as their password? How about john and john, or rick and rick. By brute force, many hackers are able to guess their way into your site. The only and best solution to this problem is to make sure that your users do not use the same word for their username and password. 2. THE PASSWORD A lot of password creation programs do not check to see if the user actually enters a password. Most often, a password of just the ENTER key can be added to your password file. This is beyond being a weak password...it goes right into being stupidly easy to crack. Make sure your password creator disallows blank passwords. Just try and hit Enter when you go to an adult site ..might work! 3. PASSWORD FILE Although it is hard to do, it is possible for someone to reverse engineer the password file. To do this, someone must have a user telnet account on the same server that is running the subscription web site. If someone does have access to the machine in this fashion, and they have read access to the directory that your password file is in, they can run a password cracker program like Crack 5.0 to decipher the passwords. The best solution to this problem is to make sure that your subscription site is on a server with no external telnet access. Consider putting your web site on it's own dedicated machine, with no other user access. 4. ADMIN SECTION Many web sites have an administration web page section where the administrator can add and delete user names. Problem is, many of these administration sections are not protected! If you go through all the trouble of putting .htaccess to protect your member's area, wouldn't it be a good idea to have a separate .htaccess with a different password file that ONLY contained your administration name and password? I think so, but many sites overlook this. So to a hacker, if they can locate your administration page, they can add ANY username and password they want to. The second part to this is that most often, the administration page is name admin.html or admin.htm. So someone browsing through your web can try adding "admin.html" to the end of the URL, like "www.thesite.com/admin.html" and, lo-and-behold, instant unlimited passwords! Change the name of your administration web page. Hackers! most often, the administration page is name admin.html or admin.htm. So someone browsing through your web can try adding "admin.html" to the end of the URL, like "www.thesite.com/admin.html" and, lo-and-behold, instant unlimited passwords! 5. LOGIN NAME CHECKER When a user tries to signup to your web page, at some point there is going to have to be a username check to see if the username they want to use is taken or not. Quite often, this login name checker is available to the public BEFORE they have paid, which means that a hacker can sit there guessing login names to see if they are taken. If they are taken, For ex: If a hacker goes to a pay site...to scope out the payment methods and layout of the payment page..Some times before he pays, he might be prompted to ask for a username to see if it is already taken or avalible! Lets say the hacker picks the username "fuck" and the page says that username is already taken..Well then he knows that the username fuck exists. And now all he has to do is Guess the password, which is a very easy thing to do!..Usually the same as the username..or something simple like mydick pussy cunt ..!!.. If your username checker is available to the public, MOVE it. Make it only available AFTER the user has paid for access. If someone finds out that "john" is already taken, he can then go and try to get into the user section using weak passwords like "doe". This isn't to say that he couldn't do that anyway, just having a login name checker available to the public allows someone to sit at it making a long list of common usernames to try. 6. FAKE CREDIT CARDS There are credit card number generators out there. These programs create credit card numbers that will pass through most credit card checkers. This way, someone can sign up as normal, but use a fake credit card number that they generated beforehand. Once they have created this login name, they then post it to a password page, and your site is finished. Fortunately, there is a way to put a stop to this. Make sure that whatever user payment system you are using records the IP address of all users that sign up. That way, if a false credit card comes through, the person who created the fake credit card can be traced. It's a little labor intensive to do this, so many sites don't bother. The hacker's IP address is your ticket, but if nothing is done about it the same day, the chances of finding out who did it is slim. Find out what Internet provider they came from, at what time, and try contacting that Internet provider to get a log of the person who was using that IP at the EXACT time you received the false credit card. However, you cannot really do anything about it at that stage other than to contact law officials and let them handle it, as the IP address can be faked as well. The only real way to stop this is for the police to monitor the suspected individual and catch them attempting the same trick another time. ---- If you want to hack using a fake credit card number and hide your ip address...Log onto a proxy server!..This will hide your real ip while travelling on the internet! ----- To actually be busted for this takes, EXTREME amount of work on behalf of the authorities,, They actually have to catch you in the act of doing this! How likely is that??...Not that likely...but never the less still Possible! 7. PASSWORD ADDER NOT SECURE Once a user has paid for their access, they are quite often thrown into a web page that asks the person to now add there username and password . This password adder is usually a program that checks if a username is free, and if it is, creates a new account. A hacker then can create one legitimate user account, then save the URL of the page where you actually create the new username and password, to go back to it at a later time and add more of his own username and passwords whenever he wants to! I personaly know of at least 5 major Adult sites that I can Go and add my username and password anytime I want by using this method! This problem can be corrected by making sure that your password adder program is secured. To do this, make it so the password adder program has to be called from a form, most likely the form that shows up after the new user pays by credit card. This form should be generated by another program that receives a PIN number or some kind of security number from the credit card checker. These pin numbers should be one time use, and be encoded into the password adder form by way of a hidden field, like . The password adder program should check also to make sure that the form that called it is on your web page by examining the HTTP_REFERRER environment variable. If it does not, someone could create a form on a DIFFERENT web server that then had it's
tag pointing at your password adding program on YOUR server. 8. PICTURES NOT IN SECURE DIRECTORIES Directory structures that are not protected by something like .htaccess are wide open for browsing, as long as a valid user finds where your pictures are stored. Let's look at a picture of a directory structure members / /usr/home/bob/public_html - pictures \ admin Now, let's say that Bob protects his /usr/home/bob/public_html/members directory with an .htaccess file. That means that members have to login to get into the members directory. Great. So Bob has some pages in the members area that have thumbnails. That's great too. Problem is, if Bob makes links from his thumbnail pictures to pictures that are stored in the "pictures" subdirectory, and the "pictures" subdirectory are not protected, then ANYONE can browse into the "pictures" subdirectory without ever logging in as a memeber...They would have full access to the pictures. By totally bypassing the members section..They just essentially have found the hidden url that stores the pictures!..Normally that url is password protected..BUT a good many times it's not!..I've seen it over and over again! A better directory structure is: /usr/home/bob/public_html/members/pictures \ admin That way, even if the pictures directory doesn't have it's own .htaccess file (in fact, it doesn't need one, the .htaccess in the members directory will protect all the subdirectories). Now, any link to a full picture file is protected, and no one can casually browse into it. 9. PACKET SNIFFING This one is a little more difficult to do, but can be a serious security hole. If your server does not allow telnet users onto it, that's good. But if your server is sitting on a network with other Unix type servers, it is possible for someone on another machine on the same network to use a packet sniffer, like SNOOP, to read passwords going into your system. All the hacker has to do here is to gain root access on a machine in the same network, run SNOOP, and wait for it to log all passwords being sent to your server. There are a couple of things you can do to prevent this. Make sure your server is on a segmented network. That means that packets destined for your machine are being routed directly to it, and not broadcast on a LAN with other machines on it. The other way to stop this kind of password theft is to get a SSL (Secure Sockets Layer) certificate for your machine, and make your member's area SSL protected. This sometimes is not an option, as not all browsers support SSL, so some of your clients may not be able to enter your website. If you read all the information above, you now know exactly how to hack your site, and how to protect against someone else helping themselves. New hacks come out every day, so to help you keep up with web security, we have created an email discussion group that you are free to subscribe to. Simply send an email to majordomo@gawd.org with the body of the message reading only "subscribe websecure" (don't include the quotation marks!) This mailing list is designed to help you, the webmaster, discuss with others about how to make sure that your systems are not comprimised. We are also able to provide you with full security consultation. If you want to make sure that your webserver is secure, drop me a line at damon@gawd.org. Please don't send me individual questions there, as I will not respond, only email me if you actually want security consulting...that's how I make money, thanks. General questions can be directed to the mailing list.