[Food for thought] JAVA and Stateful Session bean - secure?!

[cool_dude_prav]

Hello Java coders...

I have a question cum point of thought...

I am going thro' this JAVA course at NIIT and I was thinking...

Stateful Session Bean is so... secure.
It can be used for maintaining sessions on server...
If so, more secure connections can be made on server and instead of cookie sessions, EJB sessions can be used...

Then there is absolutely NO WAY for hackers to interrupt us, esp. during bank account transactions...

What do u say???

This is my food for thought...

Prav.

[GNUrag]

Note: I dont know anything in EJB and beans.

But from my perspective, one may avoid the overhead of getting into java things forever. Just why use Java and waste server's expensive computing resources?

If the prime importance is security of the session, then one should use the webserver in SSL mode always. One can pass secure parameter to PHP's setcookie function. That will make sure that everything is transmitted over SSL including the client side cookies.

Using PHP can speed up the webapplication dozens of times as compared to Java based ones.

[cool_dude_prav]

Hmm... cant u see, that cookies can always be targeted easily.
But with EJB Stateful Session Bean, u can actually make it work something like a Server-side cookie.
It is a lot safer...

I mean, this may already be used somewhere. I just wanted to know more details from here...

Cheers!!!
Prav

[GNUrag]

I already said, I dont know a thing about EJB. I would appreciate if you could educate me on that.

But what's the problem if the cookie is being transmitted over a secure SSL connection, and apart from that, SSL cookies are handled differently by the browser.

Just why use java then?

[enoonmai]

@cool_dude_prav: Let's get a couple of things straight first. EJB is the business component of the J2EE specifications, providing the business logic tier of the enterprise application. If you are talking about simple session management, then why should anyone even bother with business models for each and every site simply to provide more security. Plus, contrary to what most people think, cookies aren't all THAT bad as some people make them out to be.

Like GNUrag pointed out correctly, why get into Java at all for a simple site that can handle cookies over SSL without any other overhead? Why waste server resources at all?

However, if you are talking about general session management in J2EE, especially JSP/servlet/EJB powered portals like Citibank's or Amazon's online portals, etc. then the argument is a little bit more complex.

If you look at J2EE best practices, its recommended that if you are going for client-side session state, then the cookie should hold minimal information, since its easy for viewing/editing the cookie on the client. There are more problems to it, for example, that if the user disables cookies, the enterprise application cannot use cookies to maintain the session state. Also, since the cookie is shared between instances, the user can open another browser window to the portal (sharing the same cookie) and the enterprise application would be totally confused and there MAY be unnecessary conflicts if the coding is not 100% proper.

However, its not really a joke maintaining session state on the server. You can use the HttpSession interface and use it to store session state. The advantage is that its highly scalable and of course, a lot more secure. However, most enterprise app portals use a number of servers across which all the components are stored and depending on how much load is there on the portal and the number of hits, which may go into the millions per day for some portals. You will need to use replication across the servers to make sure the user gets a steady, unified experience. Its obviously better to store session state on the server, and most portals do use a combination of safeguards such as session timeouts and storing state on the servers instead of dumping all data on the client. For example, the state for Amazon's portals maintained on the client side is minimal. All your information is stored and accessed server-side. If you want to know more about this, check the Amazon implementation whitepaper at Java.Sun.com.

This, is however, not feasible practically for all servers, only high-volume, high-risk servers, such as online banking, etc.

@GNUrag: EJB or Enterprise Java Beans is simply the business logic tier of an enterprise application. No way connected to simple session management unless its for enterprise apps.