Client persistent storage not remembering user

[Thomas Colin de Verdière]

The database stores a sequence number per user. This sequence is
incremented each time the user connect. If the cookie is stolen, an old
sequence number is detected (from the thief or from the user) and the row
of the database is removed. So the thief can only use its current session,
if he connects before the user. If he connects after the wrong sequence
number will be detected. In case of stolen cookie, unfortunately the
process does not remove the current thief's j2ee session even if it is
detected. But the "good" user may be informed of that.

But it is true that clustering the database is a problem i did not think
of. I did not think of clustering the idp either.


2018-04-25 20:32 GMT+02:00 Cantor, Scott <cantor.2 at osu.edu>:

> > Yes the point of the approach is avoiding stolen cookie.
> > What do you mean by a lack of reliability ? You mean a bad reliability
> if the
> > database shutdown or has too much load ?
>
> Yes. You have a single point of failure. Most people don't cluster
> databases. This use case happens to tolerate a looser replicated store, but
> it's still pointless, there is no need for a database to prevent forgery.
> The advantage of the database is solely per-session revocation.
>
> Stealing a cookie isn't the threat you're addressing, forgery is. Unless
> you address-bind the cookie, there is no mitigation to theft, no database
> solves that.
>
> -- Scott
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180425/71a9adc9/attachment.html>