How Secure?

[jscheuer1]

I found this recently and was wondering how secure it is and why:


<?php

// Define your username and password
$username = "someuser";
$password = "somepassword";

if ($_POST['txtUsername'] != $username || $_POST['txtPassword'] != $password) {

?>

<h1>Login</h1>

<form name="form" method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
<p><label for="txtUsername">Username:</label>
<br /><input type="text" title="Enter your Username" name="txtUsername" /></p>

<p><label for="txtpassword">Password:</label>
<br /><input type="password" title="Enter your password" name="txtPassword" /></p>

<p><input type="submit" name="Submit" value="Login" /></p>

</form>

<?php

}
else {

?>

<p>This is the protected page. Your private content goes here.</p>

<?php

}

?>

It sure works like a charm in that neither the 'protected' content nor the password may be seen via view source until after 'logon', and then only the content.

[thetestingsite]

It's only as secure as any PHP script can be. As long as only the intended user knows the login info (and you don't show the PHP source to anyone), the content will be somewhat "protected". You could use other methods as well; such as using the md5 hash for the password or even both the username and password, but that's not practical.

Anyways, just my thoughts.

[jscheuer1]

I guess part of what I am asking is -

If someone savvy who is not supposed to see the content found the page, is there any way (without the username and password) that they could download and/or view it other than 'as served'?

And, is there any way that bots could see the content.

I want to protect a list of paying customers and their email addresses so that only folks who need to use this info can see it.

[thetestingsite]

If someone savvy who is not supposed to see the content found the page, is there any way (without the username and password) that they could download and/or view it other than 'as served'?


To my understanding; no. They would need to enter the correct username/password combo (using any form pointing to your script using POST method) before being able to see the content that is "hidden".

Hope this helps.

[Twey]

Without exploiting a vulnerability in the server software, no. This is the most secure way of protecting a page there is: there are simply no features to exploit. Of course, this has its drawbacks too, but it's certainly secure.

[alexjewell]

Yeah, it's so simple it's hard to get around. Either the password and username match up, or they don't. I use this method all the time.

[djr33]

The only possible way to hack that page, without direct access to the server, is using brute force, for both the username and password, which would be very very slow, considering.

[boxxertrumps]

download and/or view it other than 'as served'?
Bruteforce any FTP access to the page. Physical access to the machince. Your host takes a peek at what his clients have under the hood. Improper permissions set and other people on your host can get to your files...
Paranoia aside, Thats as secure as it gets.

[alexjewell]

Sometimes it's better to be a bit paranoid, though. After I had this complex PHP login with sessions and sql and everything, and within a day of it being up, someone had injected a few trojans into it that downloaded on the computer of every person visiting my site...well...I learned a hard lesson. Haha.

[Twey]

Well yes, but the software installed on the server is the premise of the host and the developers of that software, not the web developer.
I had this complex PHP login with sessions and sql and everything, and within a day of it being up, someone had injected a few trojans into it that downloaded on the computer of every person visiting my siteWhich is what we're saying: it's actually a lot harder to write a proper SQL-based login system securely than it is to use something simple like the above.

[jscheuer1]

Thanks to all for their comments on this, and please continue if you have more.

I just thought I would inject what my thinking has become on this though. As this is for a specific purpose for a specific client, and as the web space is donated for promotional consideration, and as this host has been compromised in the past, allowing their list program to be hijacked (or via some other means the mail address of the client's site to be hijacked) by at least one spammer*, and as the client really wouldn't want to have its customers suffer loss of privacy, even if this is just a possibility, simply as the result of being a customer, and as doing this would involve at least some 'training' of those within the organization who would use it to prevent them from becoming leaks and just to get them familiar with it - I have decided at this time not to use it in this case.

However, it's nice to know it's about the 'most secure that you can get', and I may use it for less sensitive data in the future.

*This resulted in at least one member of the client organization receiving tons of spam that appeared to come from the client organization's web address, and was eventually resolved by the host. There were others affected outside the client organization, but this may have been using other accounts on the host. This is the only 'breach of the host incident' I am aware of and it was resolved, but I only heard about it because one of the client organization's principals was affected.

[Twey]

and as doing this would involve at least some 'training' of those within the organization who would use it to prevent them from becoming leaks and just to get them familiar with it - I have decided at this time not to use it in this case.What are you doing instead, then? About the only more secure solution is to not upload the sensitive content to the webserver in the first place.

[jscheuer1]

What are you doing instead, then? About the only more secure solution is to not upload the sensitive content to the webserver in the first place.

Well, yes. The information isn't going on that server. I attach the local web page to an email to two of the client organization's principals. I didn't even think of that. As a result, it is potentially exposed in transit, and potentially exposed in a great many more locations, but is perhaps less likely to become a target of hackers than if it were to be a page on a server. In any event, the information, to be used, ends up in hard copy. I think that is actually the biggest potential for breach. However, I have no, or very limited control over that. Fortunately, the folks who use it are trustworthy as far as I know.

Other considerations here are that what is currently done works, and is slightly less work for me than this new idea (in my current conception of it) would be, and folks are familiar with it, and I can't control what others do with it.

It wouldn't be the end of the world if these email addresses got out. Most people's addresses already get their share of spam and there is no need to keep secret the actual identities of the customers. There is no information other than name, email address, product, quantity and price. This is not a good or service anyone should be ashamed of having used, and takes place in public where they could be observed doing it anyway. I'd just like to exercise good faith in the protection of the addresses and keep my work load down, while still delivering the information in a timely manner.

[Twey]

As a result, it is potentially exposed in transitYou could perhaps encrypt the file? PGP does a fairly good job.

[jscheuer1]

You could perhaps encrypt the file? PGP does a fairly good job.

I haven't used that in quite a long time, going back to when the messages I was concerned with went through a net like FIDO. I never had anything so sensitive that I needed it (PGP), but I was interested in the concept, so tried it out.

Unless I am mistaken, that would require a bit of a learning curve though, and a fairly steep one for any recipient who is not already familiar with it or is not at least fairly 'geeky'.

[Twey]

Not really. The setup can be a little technical, but after that it's just a case of choosing the message and clicking "decrypt" in most cases.