Best practices

[tasticeyes]

Hello everyone

Could the good people of MyBB please point me to some sources (or provide the information directly ) on best practices in the following cases:

1) Authenticating users for a JSP website (running on Tomcat). I've read that including some header in my JSP scripts that performs authentication is not recommended anymore. In fact, I've found that much of the stuff I learnt about JSP back in the day is now "depracated". What is the preferred way of doing this? For example, presenting a form to the user where they enter login details. These login details are validated against records in a database before allowing access to specific areas of the website. Is it better to do this myself, or let the container handle it (if this is indeed even possible)?

2) Slightly related to point (1) above, what is the preferred way of persisting information? Due to the statelessness of HTTP, one would need sessions and/or cookies, etc, correct? What if you want to track the browser session for both logged-in and anonymous users? What are the security implications of this? In other words, what is the correct (and safe) way to propagate state information for viewers (both logged-in and otherwise)? Sessions? Cookies? Sessions + Cookies? Something else?

Thanks a bunch!

 

[stricken]

1. Its always better to roll your own login if you know what you're doing. i prefer to use javascript to md5 hash the username and password together, and post the hash, matching it up server side to a pre-created hash of the username and password. this just ensures you are not sending password (and username) in plaintext, esp over a non SSL http connection.


2. Sessions and Cookies work together. When you set a session, the server sends the browser a cookie, that it automatically tags on to every request to the server from there on in. the server (depending on whether its PHP, ASP, JSP, or whatever) can then invoke the session on each request and store variables against it. MY pref. is PHP, but googling for JSP sessions should yield results.


But its always best to do all this over an SSL (https) connection for production systems.

This is the way everyone does it.... BUT.. i prefer to store the remote (client) IP when the session is created and match every request against it... to prevent (or at least complicate) session hijacks.

 

[tasticeyes]

Thanks for the response.

Regarding your response to point (1), consider the following (I'm not sure if I'm understanding what you're suggesting).

1) User enters username/password into a form and hits "submit"
2) Javascript hashes username+password+salt and transmits hash to server (possibly along with username?)
3) Server validates received hash against a re-computed (or pre-computed) hash.

Is that what you meant? If so, (assuming a non SSL-secured connection), what is to stop an attacker from sniffing the details sent to the server and replaying them to gain access?

I agree that using SSL is essential for securing the conversation from eavesdroppers, but it doesn't solve the issue of authentication. Any attacker can set up an SSL connection and masquerade as someone by replaying captured usernames/hashes/etc.

Am I missing the point here? Sorry for my ignorance.

Regarding the use of sessions and cookies, is that secure? Again, this seems to rely on eavesdroppers being unable to listen in on conversations (due to, e.g. an SSL protected connection). Furthermore, it doesn't seem too safe to store things in this way. Again, am I missing the point?

Look forward to hearing your comments

1. Its always better to roll your own login if you know what you're doing. i prefer to use javascript to md5 hash the username and password together, and post the hash, matching it up server side to a pre-created hash of the username and password. this just ensures you are not sending password (and username) in plaintext, esp over a non SSL http connection.


2. Sessions and Cookies work together. When you set a session, the server sends the browser a cookie, that it automatically tags on to every request to the server from there on in. the server (depending on whether its PHP, ASP, JSP, or whatever) can then invoke the session on each request and store variables against it. MY pref. is PHP, but googling for JSP sessions should yield results.


But its always best to do all this over an SSL (https) connection for production systems.

This is the way everyone does it.... BUT.. i prefer to store the remote (client) IP when the session is created and match every request against it... to prevent (or at least complicate) session hijacks.

 

[ozziej]

Well, if you are looking at authenticating users, have you got a Database managing this?
At least then you can also track things like logins, preferences etc.

Also, with persistent information, it depends on what you want to do with it.
I generally use things like session information for managing if a user is logged in, username/ email address that kind of thing.
Basically, stuff that is already present in the DB, but you don't want to have to query the DB for the whole time.
Generally you do not want to keep PASSWORDS in session info, as this can be grabbed. So only keep non-vital information (like I said above, username as an example)
Cookies are very useful for simple things like preferences on a page that you don't need to store in a DB. I usually use them for things like enabling/disabling hover tool tips.

 

[bin3]

1. Its always better to roll your own login if you know what you're doing. i prefer to use javascript to md5 hash the username and password together, and post the hash, matching it up server side to a pre-created hash of the username and password. this just ensures you are not sending password (and username) in plaintext, esp over a non SSL http connection.

It's never a good idea to roll your own login if you don't really, really know what you are doing. ... [Sorry, had to]

I would start with JAAS and take it from there: http://en.wikipedia.org/wiki/Java_Authentication_and_Authorization_Service

+1 to the SSL though ...

 

[tasticeyes]

Ok, but then (unless the connection is encrypted), it seems fairly trivial to capture the session information and masquerade as the legitimate user?

Yes, I have a table containing information that can be used for user authentication.

Regarding what I'm attempting, I want to have pages that require a user to be authenticated to see. I also don't want the user to have to authenticate every time a link is followed (this, I think, implies persisting information in session variables).

Well, if you are looking at authenticating users, have you got a Database managing this?
At least then you can also track things like logins, preferences etc.

Also, with persistent information, it depends on what you want to do with it.
I generally use things like session information for managing if a user is logged in, username/ email address that kind of thing.
Basically, stuff that is already present in the DB, but you don't want to have to query the DB for the whole time.
Generally you do not want to keep PASSWORDS in session info, as this can be grabbed. So only keep non-vital information (like I said above, username as an example)
Cookies are very useful for simple things like preferences on a page that you don't need to store in a DB. I usually use them for things like enabling/disabling hover tool tips.