[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