[TYPO3-mvc] encrypd cookies in TYPO3

Chris Wolff - AERTiCKET AG cwolff at aer.de
Tue Dec 23 13:24:28 CET 2014


Hi Helmut,
shure this discussion is getting of track but is very interesting.

I find it very interesting that you think encrypting an session id Would gain some benefit. Could you elaborate on that a bit.
Verifiability is nothing you gain from encrypting your session id. your session id is Verfifyable, you have an entry in the session table.
Maybe I am missing some point?


> The whole idea of encryption is, that it is safe to hand out data to the public. 
Shure! But encryption algorithms and and Implementations might get broken. So why take that risk. If there is no benefit from it. 

Yes there are good examples why session data storage in cookie and encryption ist good. As I mentioned in one of my first mails on this topic.
Many Ruby on rails apps do it this way. Because it plays nicely with a load balanced app where a user is not fixated on the same node every time. The 
App gets all the session data delivered with the cookie and can work without accessing a central session storage.

Regards Chris


-----Ursprüngliche Nachricht-----
Von: typo3-project-typo3v4mvc-bounces at lists.typo3.org [mailto:typo3-project-typo3v4mvc-bounces at lists.typo3.org] Im Auftrag von Helmut Hummel
Gesendet: Dienstag, 23. Dezember 2014 12:50
An: typo3-project-typo3v4mvc at lists.typo3.org
Betreff: Re: [TYPO3-mvc] encrypd cookies in TYPO3

Hi Chris,

this is gettig rather off topic, but I find it an intersting discussion anyway :)

We're mostly on the same track, I just want to clarify a few things.

Am 23.12.14 um 11:40 schrieb Chris Wolff - AERTiCKET AG:

> I put protect in quotes "Protect" because in think its generally a bad idea to Handout data to the client you want to protect.

The whole idea of encryption is, that it is safe to hand out data to the public.

> A session id is pseudo-random value. Which should by definition not guessable.

I totally agree!

> If I encrypt this value. Do not get a benefit from that.

I kind of disagree :)

> My server only has to do encryption / decryption to look up the session id.
> Encryption does not add a security value

I agree that in general there is no benefit in ecrypting a value that is truly random which results in a truly random value.

BUT: If you do so, you can verify on the server side, if you can encrypt the value. To be honest, the same could be achieved with hashing the value with a secret and vlidate it after that (hmac).

> until you add some extra data like the iP address Or user agent string. But if you add this You have implemented a session fixation Method!

I strongly disagree on this one.
Session fixation is a problem of its own where you control the session id a victim will use for a session. In this case the session id isn't a random value any more, but is kown to an attacker.

What you describe are mitigations that should prevent a session re-use in case an attacker somehow gets the current session id of a victim, no matter if this is by a session fixation or by sniffing it.

Session fixation still must be avoided, even with these mitigations in place.

Besides that, these mitigiations are really poor ones, as a user agent string is nothing un-gessable and also very easy to obtain (easier than fixate a session) and the IP is not a protection in a (very common) scenario where you share a same network with the same public IP.

Besides that, these mitigations cause problems in very common network situation nowadays (IP is switched randomly, user agent string is changed by proxies …)

I wouldn't cry if these mitigation would be removed from TYPO3 session handling and I very often suggested to disable them if users had troubles with session invalidation.

>> As a bonus, nobody could even read the content of a cookie.
> If your user should not read the data why give the data to the user in the first place?

I'm not suggesting to replace all session storage and use encrypted cookies instead, that would be nuts as the values must be transferred over the wire for every request.

The only thing that I'm suggesting here is that encryption of cookies is not bad in general. TYPO3 does not have an API for that because it is bad, but because it has other concepts (session storage in database) you could use to achieve the mostly the same.

But that does not mean, that I can't imagine a use case where it would make sense.

For anything in IT there is more than one solution. Be open to select the best one for your specific use case would be my advice.

Kind regards,
Helmut

--
Helmut Hummel
Release Manager TYPO3 6.0
TYPO3 CMS Active Contributor, TYPO3 Security Team Member

TYPO3 .... inspiring people to share!
Get involved: typo3.org
_______________________________________________
TYPO3-project-typo3v4mvc mailing list
TYPO3-project-typo3v4mvc at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc


More information about the TYPO3-project-typo3v4mvc mailing list