Simple Log In Page, No SQL or Cookies.

Here is a simple login script I found ...I am not an expert in PHP (yet)...I do not have any idea how to add an error message, when one enters the wrong pasword, but this script is very easy and simple...though might not be the most secure....it will keep the average looker out :) Works for Mozilla& IE


<?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']; ?>">


<label for="txtUsername">Username:</label>

<input type="text" title="Enter your Username" name="txtUsername" /></p>



<label for="txtpassword">Password:</label>

<input type="password" title="Enter your password" name="txtPassword" /></p>



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

</form>

<?php

}
else {

?>



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

<?php

}

?>
Source: TotallyPHP (http://www.totallyphp.co.uk)

Here.

<?php
// Define your username and password
$username = "someuser";
$password = "somepassword";
//Now lets check to see if the form has been filled out.
if(isset($_POST['user']) && isset($_POST['password']))
{
//ok they are set lets see if they match.
if($username == $_POST['user'] && $password == $_POST['password'])
{
//Ok the login worked
?>
Your Protected Page Here.
<?php
}
else
{
//Login Failed, display error
die("Your Login Information was Incorrect");
}
}
else
{
//Login Field was blank, display the login form
?>
Your Login Form Here
<?php
}
?>

why not store the $username and $password values as their hashed values to prevent disclosure?
like

$username ='dfgf5d4575gdf5g77557dfg57dfg';
$password ='7df373df7g3qfd753g37dfg3dfg7';

code to generate the hashed username and pwd:

echo 'sha1 digest username: ', sha1('your username');
echo 'sha1 digest password: ', sha1('your password');


and then change
if($username == $_POST['user'] && $password == $_POST['password']) {

to

if($username == sha1($_POST['user']) && $password == sha1($_POST['password'])){


actuually, you should put the

<?php
$username ='dfgf5d4575gdf5g77557dfg57dfg';
$password ='7df373df7g3qfd753g37dfg3dfg7';
?>

is a separate file that you store above the webroot and that you include inside your code.

Single simple Login! :)

But it can be cracked brutally if you don't use session expire after x tries.

But it can be cracked brutally if you don't use session expire after x tries.
i've never heard of a bruteforce setup where the bruteforcer is interested in keeping the session alive...
he'll just start a new session for each trial.

i've you wan't to add bruteforce-measures, then i think these are the most obvious options:
- record the IP and only allow 3 logins for an IP with a 1 hour period --> but this requires storing the IP's in a db or file so that kinda defeats this 'no db required' script + the IP can be spoofed
- add this little line

sleep(rand(5, 10));

right before comparing the posted and stored password and username
this will slow down the bruteforce so mucht that it becomes virtually impossible to make enough trials if you change the password every month or so. Downside is that valid logins also will take between 5 and 10 seconds.
- add a CAPTCHA to block out all automatic logins.

I think I'd better to use sleep(rand(5, 10)); for after xx tries with session cookie validation.

I think CAPTCHA is most suitable way coz almost all sites on the web use it already.

So are there any valunerablities or weakness on CAPTCHA ?

Some Captcha are done by means of md5(secret_key+random_num).

can they said secure ? coz once we get secret_key, .....

I think I'd better to use sleep(rand(5, 10)); for after xx tries with session cookie validation.
idon't understand what you try to say here, but if you're suggesting to only yse the sleep() after xx tries --> isn't gonna work. the cracher will not send any sessionID (not through a sessioncookie, not in the querystring and not in a hidden formfield) to your server so each trie will be considered as the first trie of a new client.

I think CAPTCHA is most suitable way coz almost all sites on the web use it already.

So are there any valunerablities or weakness on CAPTCHA ?
not hat i immedeately can think off. there is the slight chance that someone writes some soft to anayles the image and extract the characters, but that can be prevented by using random fonts, disturing backgrounds, random angles for the characters etc.
the main disadvantage is that some (disabled) users wount be able to read the characters in the image...

Some Captcha are done by means of md5(secret_key+random_num).

can they said secure ? coz once we get secret_key, .....
adding a "secret_key" to a hash-function has a completely different function then adding a secret_key to an encoding function.
it's no problem at all if the secret key (or salt as it's called in this context) and the md5() digest would get disclosed. using a salt forces a bruteforcer to compose a new digests-database for each generated captcha, which is a serious extra delaying measurement.
without the salt, he would be able to use his standard digest-database for each CAPTCHA.
anyway: if you use a captcha, then you can store the right captcha-code in a sessionvar --> that way, you force the user to keep the session alive + you can use a timeframe (like 1 minute or so) in which the user need to submit the captcha-code. this makes bruteforcing the captcha-code digest (if it gets disclosed) absolutely impossible.

idon't understand what you try to say here, but if you're suggesting to only yse the sleep() after xx tries --> isn't gonna work. the cracher will not send any sessionID (not through a sessioncookie, not in the querystring and not in a hidden formfield) to your server so each trie will be considered as the first trie of a new client.
You could force the user to have a session and that the user was on a login page before you let them log-in.

You could force the user to have a session and that the user was on a login page before you let them log-in.
not sure what you mean. i suppose you mean something like:
- when the user requests the login-form, you start a session
- when the login-form is submitted, you chech ik there is a session.
ok. so?

please do tel me how you will now check how many logins a cracker already tried to make.

because he will just not accept sessioncookies (or will delete it after every logintry) and he will reload the login-form after each trial (reloading it by requesting the url, so without the SID added to the querystring)

so each logintry will create a new session and will be considered as the first attemp.

Well I would check for the session where you said and I would not allow a login attempt without a session at all. The fact that the attacker would always have to visit the loginform and keep the session to attempt a login should slow his attack speed down enough.