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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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...

It's debatable whether session-only usage is the only valid use case  
for Horde_Secret. But that doesn't matter at all since changing this  
behavior immediately breaks production installation. Kronolith has  
been using Horde_Secret since years, the matter of fact weighs more  
than some vague API description.

We can of course migrate to a different encryption mechanism, but this  
is something that needs to be done slowly, because it cannot be run by  
an administrator. The only way to cleanly solve this, is to deprecate  
this Horde_Secret usage, migrate to a different mechanism on-the-fly,  
and only remove Horde_Secret usage a few minor or even major versions  
ahead.

Breaking APIs in major versions is fine, but breaking data  
compatibility is not allowed, ever, at least without a realistic  
migration path.

> 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.

The only valid solution for this is to allow to specify the block mode  
when instantiating the secret instance. The default would be using ECB  
for BC reasons, but CBC mode can be requested explicitly, for cases  
where we know for sure that we are working with volatile data.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject