[TYPO3-mvc] encrypd cookies in TYPO3

Helmut Hummel helmut.hummel at typo3.org
Tue Dec 23 12:50:08 CET 2014


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


More information about the TYPO3-project-typo3v4mvc mailing list