Quote:
|
Originally Posted by iota
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.
Quote:
|
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...
Quote:
|
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.