Adam,
Of course, the simple solution to the problem is to use HTTPS all the
way and yes there are SSL terminating LB's which "cheapen" the expense
of SSL but unfortunately there is still an overhead and your site will
have reduced scalability. As long as that reduced scalability is within
your limits... you are set and have the ideal solution. Having SSL
terminate at the App servers vs. the LB's is going to incur a bigger
performance penalty.
However, in our case much of our traffic doesn't even require login...
and the only clear time when there is sensitive information to protect
is when creating a membership or updating ones membership credit card
information. So SSL 100% of the time for us is far from ideal.
Here is what we do:
1) We don't use HTTPS for login ;-)
On the server we generate a "quasi" secure nonce every time we start a
sign in transaction (i.e. every time we present the form)... which
encodes part of the JSESSIONID + timestamp + remote IP address in the
nonce. Why do I say "quasi" secure because if you sit behind the same
router (e.g. over WIFI) your remote IP address obtained in Java is going
to be the same as your neighbours... so in a way this does little in
this case but is simple enough to have and guard against other cases).
On the client side we have a JavaScript function that does the following
on login form submit:
password = "SHA1:" + Sha1.hash(password);
password = "SHA1:" + Sha1.hash(password + ':' + nonce);
On the login action bean we have a validateUser event that is set to
ValidationState.ALWAYS that does the following "key" things:
- Obtains the server generated nonce node (object) from the session
using the nonce as lookup "key"
- Ensures that the nonce node is in a STARTED state (vs. an
UNINITIALIZED or other state)
- Verifies the users remote IP against that encoded in the nonce
(doesn't help in WIFI cases but does in other man-in-the-middle attacks)
- Looks up the user object using username and obtain DB user password
which is stored as "SHA1:<userPassword>"
- Compare sha1Encrypt(user.getPassword() + nonce) against
"password" passed into the form post
- If all is successful reset the nonce node to UNINITIALIZED (thus
making the entire TX one-time!!!!!!!!!!)
So what this does is the following:
a) From client through server to DB we are "never" dealing with a
clear text password i.e. its always hashed
b) As the client hashes the nonce with the users password the passed
in "password" is only useful for the life of the TX... otherwise it is
useless... and moreover on successful login the nonce is no longer
re-usable... this is KEY
So even if could steal the password over WIFI, set your IP to match the
users, you still have about 10 seconds or so (however long it takes to
hit your server, create a login bean instance (with life cycle) and
process its validation method) and thereafter the credentials are
useless... much like how a FOB providing say a 6 digits number that
changes every X seconds is appended to a password for login say at eTrade.
Is this infallible? No... but it sure helps improve performance... if
we are OK to have MOST of our traffic run over HTTP.
As far as membership or payment is concerned we switch to HTTPS and
force the user to sign in again. Likewise once they come back to the
main HTTP part of the site. In fact, many sites will force you to log
in again just to be sure it is you every once in a while or at key
points (IIRC Yahoo Mail, SafariOnline and Amazon do this) so as in our
case this is a very small part of our traffic the added log in
inconvenience isn't a big deal... and could be ironically perceived as
being overly cautious.
As someone who has spent many years working as a Senior Identity
Management / Solutions Architect I can tell you that the above solution
is not for everyone and there are other solutions available such as
using a Policy Agent / Proxy based identity management solution (Oracle,
IBM, CA, etc... all pretty much have solutions in place that utilize a
centralized hub like Identity architecture where policy agents bind into
your J2EE Application Server and can enforce Authentication and
Authorization (URI based and even Role based with standard Web.xml
security bindings).
But alas for most Internet sites today were a lot of traffic is
non-sensitive - as you point out - a 100% HTTPS OR a full blown Identity
platform - may indeed be overkill. Like anything else, Security is
always a trade-off of things, and a ring like layered approach works
best IMHO... you just have to decide how many rings you are going to
have and how thick those rings need to be. When / where to use HTTPS is
just one piece of the puzzle.
HTH ;-)
--Nikolaos
Adam Stokar wrote:
We've noticed a difference in performance on our servers using http vs
https so figured if we could use some code to handle this issue vs
upgrading our servers. I don't really agree that if you secure the
site with a login that everything should be secure. Digg, for
example, doesn't need to encrypt its news feed after you login because
the information is not sensitive. Many sites I've seen have
non-secure content after logging in. Was hoping there was an easy way
to do it in Stripes but I guess not.
On Mon, Jan 31, 2011 at 10:19 AM, Stone, Timothy
<tst...@barclaycardus.com <mailto:tst...@barclaycardus.com>> wrote:
Couldn't this "use case" also be addressed with OAuth? Where the
Auth is
performed over OAuth, but the site remains over HTTP (non-secure).
I do agree 100% with Janne though, HTTPS is cheap. If the
username/password, and the services provided by the webapp should be
secure, make it secure 100% of the time, e.g., redirect to HTTPS
immediately on hitting the site.
Regards,
Tim
-----Original Message-----
From: Janne Jalkanen [mailto:janne.jalka...@ecyrd.com
<mailto:janne.jalka...@ecyrd.com>]
Sent: Monday, January 31, 2011 9:48 AM
To: Stripes Users List
Subject: Re: [Stripes-users] HTTPS to HTTP switching
> 1) Logging in. The login action should be https so username and
> password are encrypted, but once i pass the login, the first
page the
> user sees does not need to be secure, hence switching from https to
> http
And that's exactly when your site stops being secure, and the user
session can be hijacked, and your site is compromised. Facebook does
login over https, yet the sessions can be hijacked. That's why they're
rolling out the change...
Please *do* seriously consider using https all the way after the user
has logged in. You have very few real reasons why you shouldn't -
https
is very cheap these days with SSL-terminating loadbalancers and
plenty-of-CPU power for decryption anyway. You're otherwise creating a
fairly easy-to-exploit security hole in your system... (unless, of
course, you can ensure that nobody ever uses your system over WiFi.)
/Janne
------------------------------------------------------------------------
------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better
price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February
28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
Barclays www.barclaycardus.com
<http://www.barclaycardus.com>
This e-mail and any files transmitted with it may contain
confidential and/or proprietary information. It is intended solely
for the use of the individual or entity who is the intended
recipient. Unauthorized use of this information is prohibited. If
you have received this in error, please contact the sender by
replying to this message and delete this material from any system
it may be on.
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better
price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
