[dev] [commits] Horde branch master updated. 4cb34e7b8709aaf32f63a830f0214e2d241e66cc

Michael M Slusarz slusarz at horde.org
Fri Mar 6 04:06:21 UTC 2015


Quoting Jan Schneider <jan at horde.org>:

> commit 34ae947ba0d340203b897273cdf1688466963d80
> Author: Jan Schneider <jan at horde.org>
> Date:   Mon Mar 2 14:49:30 2015 +0100
>
>    Revert "[mms] Use more secure CBC block cipher mode when storing  
> encrypted Blowfish data inside the session."
>
>    This reverts commit d4feab0e8f873e247c95d298d61d57ce4d1f24c2.
>
>    This broke *any* encrypted data stored permanently somewhere in  
> Horde, e.g.
>    remote calendar crendentials.
>
>    Bug: 13869
>
>    Conflicts:
>    	framework/Core/package.xml
>
> framework/Core/lib/Horde/Core/Secret.php |   21 ---------------------
> 1 files changed, 0 insertions(+), 21 deletions(-)
>
> http://github.com/horde/horde/commit/34ae947ba0d340203b897273cdf1688466963d80

 From the Horde_Secret documentation:

   * Provides an API for encrypting and decrypting small pieces of  
data with the
   * use of a shared key stored in a cookie.

In other words, Horde_Secret only supports (read: was designed for)  
encryption of data within a single session.  That's kind of the whole  
point of it, since permanent encryption can be handled by directly  
using whatever encryption library is needed without any of the added  
overhead/complexity.

Horde_Secret was not meant as an abstraction for a general encryption  
function for use in Horde; it was intended as an abstraction to allow  
encryption within a session without having to worry about  
generating/preserving the key.

Kronolith should not be using Horde_Secret to be encrypting data  
intended to last indefinitely - it should directly use whatever  
encryption function/library is desired to store this data, whether  
that be blowfish, AES, rot13, etc...

So this code needs to be added back to provide valid session security  
since this removal can be considered a security regression - a user's  
password can be recovered by obtaining only the encrypted value, which  
may live on a separate machine from the PHP server (session storage;  
and something like memcache can be accessed from anyone that gains  
access behind a firewall, for example, since it is not authentication  
protected) and sniffing the browser cookie data; CBC requires the  
additional knowledge of the secret key which would require actual  
access to the Horde configuration file also.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the dev mailing list