Hi Christopher:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
John Caron wrote:
Our application is serving large amounts of scientific data over HTTP.
The user needs to login to access the data. We would like to use session
ids to reduce the login overhead. We cant afford the overhead of HTTPS
encryption of teh data (3 times slower ?).
I think that SSL is much slower than that. Usually, special hardware is
required to make SSL perform well enough to handle heavy traffic.
A recent paper estimated 3-9X slower, but for my problem (large binary file
transfer) Im guessing 2-3X for fast CPUs. That paper, BTW, suggests that faster
general CPUs are the way to go vs specialized hardware.
Performance Analysis of TLS Web Servers
CRISTIAN COARFA, PETER DRUSCHEL, and DAN S. WALLACH, Rice University
ACM Transactions on Computer Systems, Vol. 24, No. 1, February 2006.
We realize this makes us vulnerable to session hijacking. Still, we
arent transferring financial information, so tentatively we think its
a reasonable risk.
<soapbox>
Just make sure that your users don't use the same username and password
they use for their online banking. Seriously. That's the worst part of
all these websites these days that don't use SSL: it's not that the
passwords go in the clear (what do I care if someone hacks into my
NewYorkTimes.com account?), but that most people use the same
credentials for everything, because it's easy. You might want to put a
warning about that on your site.
</soapbox>
We plan on using SSL to do the initial authentication, but then use session ids
without SSL for the data transfer.
# Some services make secondary checks against the identity of the user.
For example, a web server could check with each request made that the IP
address of the user matched the one last used during that session. This
does not prevent attacks by somebody who shares the same IP address,
however, and could be frustrating for users who's IP address is liable
to change during a browsing session.
Like AOL users, and some others going through proxies, etc. It's a
relatively effective mechanism, and you might want to allow users to
opt-in to this type of thing. You'll notice that some sites have a
checkbox in the login form that says "Restrict my session to this
computer", and when that's enabled, you do the IP verification. That
allows AOL (or other) users to opt-out of the security mechanism.
Hmm I didnt know that about "opt-out" security. We arent really doing web sites, we are enabling data access by scientific programs.
# Alternatively, some services will change the value of the cookie with
each and every request. This dramatically reduces the window in which an
attacker can operate and makes it easy to identify whether an attack has
taken place, but can cause other technical problems (for example,
preventing the back button from working properly, on the web).
This is likely to cause problems with the browser getting out of sync
with the server. Also, I'm not sure if you can change the session id in
TC, so you might not be able to do this without a bunch of hacking
around in the TC session code.
yeah, im thinking i prefer the IP check, since our users tend to not be dialup. But Im
wondering if i will have to "hack around" the tomcat code to do IP checking.
I would like to implement one or both of these in Tomcat: 1) IP checking
and 2) session id switching. I guess others have thought about this.
Does anyone have any advice or pointers (or code!) to get started.
What are the implications of session hijacking for your service? Do you
have any trade secrets or anything like that which are considered
sensitive? What about potentially destructive modes of operation -- for
instance, can a user delete or otherwise modify data? If you generally
have read-only data, you might not need to worry too much about session
hijacking.
Its read-only, and no trade secrets or $$ involved. So im not convinced we even
need to worry about session hijacking, but i'd like to know what are options
are.
One other thing you should probably do is reduce the session timeout
from the default of 30 minutes to maybe 5 minutes. You'll close the
window a little more for anyone who is snooping.
good idea, thanks.
Another method that you didn't mention (but that the Wikipedia entry
does mention) is the use of very long session ids. This reduces
guessability of the session id, so someone is very unlikely to, through
dumb luck, guess a currently valid session id. Newer Tomcat versions
(not sure which) allow you to specify the number of characters in the
session id. The default is 16, but I'd imagine that you can go up to
some crazy number like 4096 or something. I don't recommend
4096-character session ids ;)
Without SSL, though, remember that anyone who is capable of hijacking
the session is probably also capable of sniffing your users'
credentials. What are the implications of that? If it is unacceptable to
have your credentials go over the network in cleartext, then you will
simply have to break down and use SSL.
I'm glad to see that someone is actually thinking about security issues
instead of implementing something that sounds good. Nice job, John!
thanks, but i havent done anything yet!
i appreciate you time in thinking about this issue.
John.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
