JSP Security Issue

Slaanesh

Hi,

In the company here we supply mp3 jukeboxs. We have loads of boxes out on site and have sold boxes to other operators. I have written a JSP page that allows these operators to log in and generate their own music selections.

However, the way I have implemented the secure login I don't think is wise, or sufficient.

Basically, I have a table called users, in this table there are a number of fields, but for login purposes I have a username and password field. The pw field is in plain text. A query is done on this to validate the user on the site. When validated, I basically just store a variable in the session saying that the user can jimmy about the site unless the session expires or they log out. It's not so much that any valuable information can be gained from hacking this, just malicious annoying attacks.

Sorry if I've worded this craply, it's just I'm very busy. What's wrong with doing it this way ? Is there a better alternative ?

Slaan.

Art_Wolf

Yeah there are much more secure ways of doing this - google php login script or such

One way of doing it is sending the password thought hpaccess or such and saving that into the table etc and also look into using php sessions

Slaanesh

Surely there is a JSP way and I wouldn't have to resort to another mechanism ?

Slaan.

Zab

JSP provides authentication with the request. You should be able to set these up in whatever implementation you are using.

Art_Wolf

Ah Ive only started looking at JSP so I have no clue in that respect though your most likly correct

This came up from google Site User Logon with XML, Java Beans and JSP and I see yeah this again uses not just jsp but notice that it doesnt use cookies or such though Il leave it up to others to decied if it is 1. secure and 2. more secure

clearz

I think the way you are doing it at the moment is perfectly fine. The easist way I would go about it is to use an sql statement

SELECT user FROM userTbl WHERE user='username' AND pass = 'password'

After getting the ResultSet call

if(rs.next()) // found a record with a matching username and password
create a new session or add a flag variable to the session.

That is fine and is the way most basic sites go about it.

Slaanesh

yeah that's pretty much the way I'm doing it, thanks clearz.

Slaan.

Harry Lime

Hi Slaanesh,

if you are using Tomcat, have a look at Tomcat realms , it will give you the added functionality of associating roles with the users, and you don't have to worry about creating the sql query yourself etc.

In your web.xml you can specify which url patterns are to be protected, the url of your login page etc.

bambam

If you want a more secure approach, you could store the password, hashed in the DB (ie use a message Digest algorithm like SHA). You would store the encrypted password and the seed used to hash it as one concatenated value.

When a user provides a cleartext password you would select the corresponding hashed password from the DB. Then using the seed (attached to the hased password), encrypt what the user has provided. If this equals what you have stored in the DB then the user has provided the correct password.

With this approach, even if someone was to gain access to your system, all they get is a lot of useless encrypted passwords.

On another note, you may also consider putting if some protection against SQL Injection attacks. This is where people enter SQL statements for a user name and trick you application into executing the SQL. A simple & effective approach is to reject any SQL keywords and spaces in the username.

And another note, you should try to force users to have strong passwords. Have rules that force say 8 characters long, must include numeric & must have mixed case. There is no excuse for weak passwords. You should enforce these rules within your code.


All this might be a bit over the top for your app, but you need weigh security effort against the consequenses of someone gaining unauthorised access.

Slaanesh

Thanks for that information lads. I've done security and encryption techniques in college, I do however think implementing something like SHA-1 a little OTT for this project. I just don't want someone deleteing or inserting loads of orders for the laugh. We will be creating the customers username and supplying them with strong password so there is no worry of having crappy passwords.

I don't think many customers will use this system, hopefully only about 50-100 which isn't much. They can't create an account through the web page, they must contact us first. I will have a look at that realms stuff though, looks interesting.

Thanks.

PhilH

Implementing SHA is not something you should have to do. The JDK has an implementation, so all you need to do is use it - a few lines of code is all you need.

It's a fair enough call to decide that you don't want to bother with realistic security, but what you consider sensitive might be different from your customers thoughts on the matter. Maybe you'll get a customer who is really paranoid about other people knowing what they listen to (maybe they listen to a lot of country music, for example).

Now that's a little exagerated, I know, but the scheme you have outlined in your original post should not be considered 'okay' for real-world applications (its fair enough if your happy to have a very low-secuirty app like you describe)

Kobie

Hi Slaanish,

What you're doing is fine for a small non-critical site providing you're not doing anything silly like showing the passwords etc in the HTML that's being sent back to the browsers. You might also want to set a username field in the session rather than just a flag so you can identify the user if you want. The session exists only on the server, so nothing you put in there can ever be seen by the user. The cookie by default (if they allow them) only identifies the user to the server so it knows which session the user has.