Say I am looking to create a forum (let's pretend) for future sale, I would like to make sure that pirates aren't going to have a hay day with it before it goes live.

and I would like to create a hidden user that has super-duper administrator access, so I can manually go in there and make alterations to the site At Will (like delete all files soever, etc.) should one of those pirates rip me off, and their hosting company take too long to respond to my DMCA/complaints.

I don't need help with the super-duper administrator access thing at this point, but...


How would you go about creating an invisible user?

as far as I know, when you create tables with user information- that information is easily seen/reflected through PhpMyAdmin- how would I go about hiding that?

---

I imagine I am not thinking out of the box enough on this?

perhaps a hidden user can be created through another section of the database altogether, and not so blatantly in the more obvious places (i.e. where all the other users and there information is going to be located)

any direction or advice on how to conceal such a user, or how to go about creating him- would be very nice to hear.

you could store user account as constants in an include

PHP Code:

define('SUPERUSERNAME', 'Lashtal' );
define('SUPERPASSWORD', 'w3lc0me' ); 


or you could lock it down using .htaccess until you are ready to go live

Originally Posted by davidj

you could store user account as constants in an include

PHP Code:

define('SUPERUSERNAME', 'Lashtal' );
define('SUPERPASSWORD', 'w3lc0me' ); 


or you could lock it down using .htaccess until you are ready to go live

If you do that, store the password as a one-way encrypted hash. If your site is on a shared host, your files could potentially be read by a snoopy hacker who knows what he or she is doing. I know it is possible because I've done it myself in an experiment, viewing dozens of PHP files that I should not have been able to see. Never assume that your PHP source will be invisible to all.

If you do that, store the password as a one-way encrypted hash

if you do that then you have access to the same user name and password as a constant

as a hash (md5 for example) is one way encryption then how does this protect the developer???

you lost me mate

PHP Code:

I know it is possible because I've done it myself in an experiment, viewing dozens of PHP files that I should not have been able to see. Never assume that your PHP source will be invisible to all. 


How did you do this? and which commercial host was it?

Originally Posted by davidj

if you do that then you have access to the same user name and password as a constant

No, because even if I know what the hash of a password is, I can't predict what password causes that hash algorithmically without a brute force attack. So the user (you) enters the password as normal when it is submitted via the form, but the program hashes the input before comparing it to the variable you have preset. This is how passwords should be kept if they are stored in a database also, because you can never 100% guarantee that no one will ever be able to see the database.

Originally Posted by davidj

How did you do this? and which commercial host was it?

I'm not going to post publicly how I did it. I may blog about it at some point, because I have several security recommendations that I compiled as a result of the research. Even then, I am not going to post the code I used to accomplish it because I don't think people should be doing it. The vulnerability is not due to the host, but rather the fault of the website owners, even in ignorance, and is due merely to the conditions of a shared hosting environment, especially when a unique IP is not assigned to a website. It was not a very difficult puzzle to figure out, and it only took me about 30 minutes to gain complete control over a database and blog once I found a certain vulnerability, though I didn't alter the website except to put an extra comma in one of the posts.

Originally Posted by davidj

you could store user account as constants in an include

PHP Code:

define('SUPERUSERNAME', 'Lashtal' );
define('SUPERPASSWORD', 'w3lc0me' ); 


or you could lock it down using .htaccess until you are ready to go live

I assume if I go this route, and I use a one-way encrypted hash, i'm probably going to want to encrypt the entire code/page with zend. (even though I know people can decrypt Zend, though not always 100% perfectly)


What do you guys think of this battle plan?

Using the Zend optimizer is fine for performance, though I wouldn't think of it as a security measure. Don't allow the world or the group to have read permissions on that file. In other words, permissions should be 711 or another configuration that does not allow anyone other than the owner to read the file. It is because of vulnerable permissions that I was able to read files with sensitive information in them. Keep this type of file very small and away from other files.