Securing user table with sha function

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
.

Relevant Pages

  • Re: Linked Table-Embed Password
    ... > for the one login was the security. ... Don't confuse data security issues with data integrity issues. ... It may be common, but it's not secure. ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)
  • Re: Logins and mdw file
    ... If you can get in without a login, ... Creating userids and passwords in an MDW file DOES NOT secure the file. ... You need to make backup copies of your files, then read the security FAQ. ... > I have three Access programs running on a variety of PC's ...
    (microsoft.public.access.formscoding)
  • Re: How do I protect my login page from prying eyes (forms authentication)?
    ... Sure, do this if you want to, but I'd rather devote time and energy to making my site secure even if someone discovers the "protected" site. ... Once it's out in the open (and if it's believed the contents are high valued, and people suspect that you've hidden the login page as a security measure), you may be *more* likely to be attacked. ... This means that when the site owner prints an invoice, the URL of this page will be shown in the footer. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How do I protect my login page from prying eyes (forms authentication)?
    ... I suppose I could have the login page in the main site (ie not ... >>At the end of the day though, you're just practicing security through ... Have the secure website generate invoices in the non-secure site, ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: How to allow users to change their password?
    ... be set up to provide the Security dialog window for password changes. ... I'll have to login using their login ... > name/password first. ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)