But because our students and employees are all around the world, I wrote a little apache module to obfuscate the cookie using a session identifier and a user key only known by the user's browser - you will need it to decrypt the session. So if somebody steals the session database it will be useless for him - without the user's key he (or she) won't be able to use the session.
For those who don't want to store "basic username:password" as user cookie on
the browser, we decided to publish the apache module we use here to anonymize
the session cookie.
It refers to request nr 000698,
http://www.sogo.nu/bugs/view.php?id=698
I am using 64 byte XOR keydata stored on the browser's cookie cache (and not in
the session database) with which the username:password-data is "crypted"
(XOR'ed) and stored in the session database. At any time this key sent by the
browser is needed to get the real "SOGo cookie" to form a session. 64byte
should be sufficient to outlength a normal SOGo cookie length - forming a
perfect OTP algorithm (XOR keylength > message length). The browser stores the
session identifier and this 64 byte "user key". Only the session identifier is
stored in the session database.
Here is an example of the resulting cookie (click to enlarge):

SOGo is a great product and we like it and also how it evolves and how requests
are handled. We had a problem however to store passwords in the browser's
cookie store when we cannot control the browser's environment (example:
Internet site in Abidjan, Ivory Coast or Douala, Cameroon (where I sometimes
reside).
The obfuscation/anonymization with user key is done by an apache module, it can
be found here:
http://southbrain.com/software/sogosession/
Be sure to read
http://southbrain.com/software/sogosession/NOTICE
before.
the browser, we decided to publish the apache module we use here to anonymize
the session cookie.
It refers to request nr 000698,
http://www.sogo.nu/bugs/view.php?id=698
I am using 64 byte XOR keydata stored on the browser's cookie cache (and not in
the session database) with which the username:password-data is "crypted"
(XOR'ed) and stored in the session database. At any time this key sent by the
browser is needed to get the real "SOGo cookie" to form a session. 64byte
should be sufficient to outlength a normal SOGo cookie length - forming a
perfect OTP algorithm (XOR keylength > message length). The browser stores the
session identifier and this 64 byte "user key". Only the session identifier is
stored in the session database.
Here is an example of the resulting cookie (click to enlarge):
SOGo is a great product and we like it and also how it evolves and how requests
are handled. We had a problem however to store passwords in the browser's
cookie store when we cannot control the browser's environment (example:
Internet site in Abidjan, Ivory Coast or Douala, Cameroon (where I sometimes
reside).
The obfuscation/anonymization with user key is done by an apache module, it can
be found here:
http://southbrain.com/software/sogosession/
Be sure to read
http://southbrain.com/software/sogosession/NOTICE
before.

Leave a comment