Is this authentication method secure?

Question

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

Pretty much, this is the logic I will follow:

Registration:

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

Login:

User provides user name and password over HTTPS.

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:

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?

SHA-1 is not an encryption. It’s a cryptographic hash function. — Gumbo, Nov 06 '10 at 21:28
It's a java servlet environment. Sessions would be stored using HttpSession.setAttribute and retrieved using HTTPSession.getAttribute — Brian DiCasa, Nov 06 '10 at 21:29

score 3 · Answer 1 · edited May 23 '17 at 12:11

3

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.

edited May 23 '17 at 12:11

Community

1
1

answered Nov 06 '10 at 21:25

Matthew Flaschen

278,309
50
514
539

score 3 · Accepted Answer · answered Nov 06 '10 at 21:27

3

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

answered Nov 06 '10 at 21:27

thejh

44,854
16
96
107

score 2 · Answer 3 · answered Nov 06 '10 at 21:31

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.

Is this authentication method secure?

3 Answers3