Your DB still has to link user X with the other table which has their contact info, or the login is kinda useless, as you don't know who they are easily... I suppose that after authentication you could look up the user ID in a totally separate query... But now suppose they change their email address. You've got to have a page to alter their SHA-encrypted data, driven from the contact info table. Seems to me that you then have to be super extra careful that nobody can mess with that page to wipe out the SHA data, or just over-write user X with user Y data... Not sure you really gain all that much, and it seems like the hassles are going to outweight the benefits... On Sat, February 17, 2007 4:45 am, Tim wrote: > 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 > > -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
