While I agree with you that putting session data in a cookie is a risky idea, I had a question:
I have even written my own session handling wsgi middleware just because I don't understand encryption and cannot find a framework that doesn't try that.
You wrote your own library that stores in plaintext because you weren't sure that pre-existing libraries were doing crypto correctly?
Why couldn't you treat those other libs' ciphertext as plaintext and apply your custom security engineering to it.
Session id in a secured cookie and then loading the session from db/memcache/ram/custom-backend is standard practice and is something that is provided by most frameworks. What exactly did you gain by using a non-signed cookie other than opening yourself to replay attacks? If you felt like directly setting a cookie instead of just `session['user_id'] = some-user-id`, why did you forgo signed cookies?
Comments
While I agree with you that putting session data in a cookie is a risky idea, I had a question:
You wrote your own library that stores in plaintext because you weren't sure that pre-existing libraries were doing crypto correctly?
Why couldn't you treat those other libs' ciphertext as plaintext and apply your custom security engineering to it.
No I wrote a library that stored a UUID as a cookie, then wrote that as a keypair with the user details to a backend dbase.
No crypto, just a lookup. Yes it introduces latency. But it is as secure as my servers are.
Session id in a secured cookie and then loading the session from db/memcache/ram/custom-backend is standard practice and is something that is provided by most frameworks. What exactly did you gain by using a non-signed cookie other than opening yourself to replay attacks? If you felt like directly setting a cookie instead of just `session['user_id'] = some-user-id`, why did you forgo signed cookies?