Stateless authentication using cookie

fabioxgn · 2016-02-05 18:59:05

I'm trying to implement a stateless authetication, which by stateless I mean: no in memory session and nothing on server (apart from the first authentication) and I'd like to know if there is already something like this implemented.

What I need is a flow like this:

- User calls the login method
- Server auth him using the database
- Saves his ID and some other info in a cookie
- Then create a HMAC "hash" using a secret key + the data on the cookie and save this in the cookie
- After this, every other request he will send this cookie and the server will recompute the data in the cookie to match the "hash"

This is something like amazon does with pre-authenticated URLs, but I'm storing in a cookie.

Is there something like this already implemented in mORMot?

AFIAK all the authentication methods saves the session on server, so with a load balancer mixing requests between nodes the user would have to authenticate in all nodes, which I want to avoid.

mpv · 2016-02-06 10:53:23

In fact your schema security level is the same as for already implemented Basic authentication. Even if you calculate HMAC, If I intercept any network package and got a session cookie I can do anything without knowledge of actual password. So the only way is to use HTTPS. Even in this case I can replace the SSL certificate (like a China Create Firewall or Kazakhstan do) and got your cookie.
In our productions we use mORMot secure RESTful authentication (modified a little) and either a load balancer what guaranty all packages from the same IP address go to the same server (almost all Cisco hardware LB can do this) or set up a DDNS and resolve a server host name to the different IP address depending on caller IP.

Last edited by mpv (2016-02-06 10:56:20)

fabioxgn · 2016-02-06 23:57:01

mpv wrote:

In fact your schema security level is the same as for already implemented Basic authentication. Even if you calculate HMAC, If I intercept any network package and got a session cookie I can do anything without knowledge of actual password. So the only way is to use HTTPS. Even in this case I can replace the SSL certificate (like a China Create Firewall or Kazakhstan do) and got your cookie.
In our productions we use mORMot secure RESTful authentication (modified a little) and either a load balancer what guaranty all packages from the same IP address go to the same server (almost all Cisco hardware LB can do this) or set up a DDNS and resolve a server host name to the different IP address depending on caller IP.

My first option was to use http basic and save the user id in a cookie, but as I'm using a Delphi client, that meant storing the credencials on the client executable (as the user have a different login in the database), so I was thinking that this approach would be better, as if the user authenticate on the database once, which would be the the first thing that the Delphi client would do, before allowing the user in and then after that, any node would trust him.

We are using https, and we are using Amazon ELB autoscalling features, so at a give time there might be 1 or 10 servers (servers will start and terminate based on the current load), so I'm trying to avoid having any state at all on the server to avoid making the user login more than once.

I don't know anything about this kind of SSL certificate replacement, can it be avoided or, even with https a MIM attack could happen?

edwinsn · 2016-02-13 12:34:46

I'm not able to help, but I'm interested in this topic.

fabioxgn · 2016-02-15 16:41:54

edwinsn wrote:

I'm not able to help, but I'm interested in this topic.

I've implemente this using jwt.io, please see: http://synopse.info/forum/viewtopic.php?id=3167

edwinsn · 2016-02-16 04:38:34

fabioxgn wrote:

edwinsn wrote:
I'm not able to help, but I'm interested in this topic.
I've implemente this using jwt.io, please see: http://synopse.info/forum/viewtopic.php?id=3167

Thanks, is your client html/js or Delphi? I mostly interested in JS (in browser)

mORMot Open Source

#1 2016-02-05 18:59:05

Stateless authentication using cookie

#2 2016-02-06 10:53:23

Re: Stateless authentication using cookie

#3 2016-02-06 23:57:01

Re: Stateless authentication using cookie

#4 2016-02-13 12:34:46

Re: Stateless authentication using cookie

#5 2016-02-15 16:41:54

Re: Stateless authentication using cookie

#6 2016-02-16 04:38:34

Re: Stateless authentication using cookie

Board footer