Hello, 1) If you protect your site from SQL Injection, you must replace all quote and blank character in your form data. (with string functions) 2) After this step, you can compare your password (with SHA1) and database password field (with SHA1). 3) if comparing passwords are true, then you must use session variables for username 4) if user forget his or her password, you can send email to the user when the user answer password protected question. -- Haydar TUNA Republic Of Turkey - Ministry of National Education Education Technology Department Ankara / TURKEY Web: http://www.haydartuna.net ""Tim"" <user@xxxxxxxxxxxxx> wrote in message news:001c01c75280$b81abcc0$1700a8c0@xxxxxxxxxxxxxxxxx > Hello, > > Now moving on into other aspects of security :P I was thinking of a way to > secure my login inputs the best way possible. > Seeing how many different types of injection attacks their is and while > observing different authentication systems I often notice the sha() > function > being used for passwords, which of course is the minimum requirements to > saving passwords but.. Why manipulate this information in clear text > wether > it be email or username or pass fields, such as when you use > sessions/cookies, or any other method of passing authentication > information > from page to page (an sha hash is x times less "geussable" then any other > human term)... AND how to secure for injection attacks? > > Now this is where i thought hey, on every login page there is a user and > pass input field and thus this is the only place one could "peak" into my > user table, and I don't want someone injecting through their as the user > table (three fields seperate from profile, username, email, pass) is the > key > to entry to the site.. SO, why not just encrypt all three fields? And > store > "copies" of email and username (not pass :P) in another database > unecrypted > or with a salt for further recovery.. > > This would ensure that ANY information entered into the user and passowrd > will be run through sha() thus creating a 40 char length hash and covering > any (?) injection possiblity through a forged input in one of those fields > via my "select" routine.. > > Just wondering what other security conscious people think of this "plan" > even though it may slow down logins a tad but the tight security in my > opinion justifies this.. > > Does anyone see an ugly flaw in this scheme? > Does it look viable? > > Thanks for any input, > > Regards, > > Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
