If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

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

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

PHP Code:

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.

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.

Originally Posted by iota

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...

Originally Posted by iota

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.

I'm not sure if this was any help, but I hope it didn't make you stupider.

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.

I'm not sure if this was any help, but I hope it didn't make you stupider.