Is this authentication method secure?

I'm in a situation where I need to create my own authentication for a web application, and I 开发者_JS百科want to get some input into how secure my approach is.

Pretty much, this is the logic I will follow:

Registration:

1. User sends over their user name and password over HTTPS.
2. Password will be encrypted using SHA1 and stored in the database.

Login:

1. User provides user name and password over HTTPS.

2. Password is converted to SHA1 and compared against the password in the database

   IF the passwords match

   the users id will be stored in their session under the user_id key.
   

   ELSE

   the user will be directed back to the login page
   

Logic that is performed before pages that require authentication:

1. The user's session will be checked to see if their ID is stored

   IF the user's id is found in their session

    user is permitted to view the page
   

   ELSE

    user is given a 404 response.
   

So how secure is this? Am I missing anything I should be doing?

Thanks for your input.

UPDATE:

Some people wanted to what environment I'm using - I'm working in a java servlet environment. To my understanding java stores sessions on the server, and just stores the sessionid in a cookie. Which makes me wonder if java's HttpSession has measures to ensure that someone's session key can't be stolen?

This part seems to be ok except what Matthew already said. Some things you should also think about:

• protect your page aganist:
  • Cross-site scripting
  • SQL Injection
• make sure that the session cookie is HTTPS only

You should also use a random per-user salt. That way, if the database is stolen, cracking must be done per-user, and they can't take advantage of, e.g. known SHA1 sums (sites like this), known rainbow tables, or two of your users with the same password.

you will have to force people to change the passwords they forget since you will not be able to send them their passwords.

if you use sessions only, you will not be able to implement "remember me" type functions. for that you will have to store cookies on the client browser. at that time storing the userid only will be a terrible idea. you should generate some kind of separate token, like a guid, or some unique random string and map that.

instead of a 404 response, you should take the user to the login screen (in case their session has timed out) and if they login successfully, redirect them to whereever they were trying to in the first place, failing that atleast send something relevant like forbidden or unauthorized.

you might want to add captcha to prevent a script which can do a brute force attempt to try common passwords.

you might want to have a counter for failed attempts and block out accounts that fail too many times for a short time say 15mins.