Hi Jeromy,
Thanks for the comments.
I'm trying to steer away from javascript for the solution in order to
maximise browser compatibility (this app may be used on older mobile
phones).
I'm hoping that AES encryption isn't cracked ;), and by the inclusion of
some random noise in the properties list it should reduce the chances of
a simple brute force attack by increasing the length of the encrypted
data and not making the plain text obvious.
I can understand the problems with your plugin, My architecture stores
only the userId in the session and gets the user from the database as
needed (due to the back end being JPA/Hibernate and the user having
ManyToOne and OneToMany relationships I can't simply store the user in
the session). The system I'm going to implement will decrypt the data
from the cookie, verify it as valid, and then populate the session with
the neccessary information, all of which will be serializable objects
(Long, String, etc.)
Thanks again,
Al.
Jeromy Evans wrote:
Al Sutton wrote:
Dave,
I'm completely agree it's a great idea and useful thing to do, but
the problem is what to put into the cookie and how to map it to the
user.
My current favourite is encrypt the properties you want to store
(using AES for speed and JCE support), then decrypt and inject when
needed. Cookies should be considered limited to 4K (due to the joys
of RFC2109 Section 6.3), so as long as the data fits joy shall be
mine :).
Al.
Hi Al,
Just another variation I use where the useragent requires javascript:
authenticate the user and generate a token; the token doesn't contain
any sensitive data;
the token is saved in a cookie and included in all requests (as
cookie, header or param)
an s2 interceptor checks the token is matched to an authenticated
user. it injects relevant details to actions
(eg. a store maps tokens to users; server-side manages expiry,
concurrent logins etc)
It's not as fast as encoding login information in the cookie but it
can't be broken. I use the same method to sign XHR requests.
If the user has checked the "remember me" box the javascript gets the
token from the cookie and resumes using it. The server it knows not
to invalidate that token.
Vulnerabilities:
- The token should be unguessable to minimize forged requests;
- as javascript is inscecure, tokens can be stolen from the cookie
(eg. by an advertisement, XSS)
I wrote the above as an S2 plugin. The only problem with releasing it
as a plugin is that the "service that checks tokens" can't be
Xwork'@Inject'ed into the interceptor (rather it has to be injected
via spring or guice) due to its potential external dependencies (eg.
an EntityManager). The same plugin also allows me to apply roles to
action methods (jsr-250).
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
