Tweaked and committed, thanks.

I am using base64 to convert the binary-ish output from the Secret 
class into something more string-friendly. Without it, the prefs page 
fails to render. Turns out the md5 hash was a holdover from an earlier 
interation - I've removed it.



I added a check for a valid password credential. Now if the password 
is unavailable, the remote calendar credentials will be stored in 
plain text in the preferences table.

The calendar management looks good, though I don't know what the md5() 
and base64 are for.

And you should check whether there are credentials provided in the 
first place, both when saving and when using them.



Regarding the password changes, hooking into Passwd would be slick but 
I can't imagine a nice and clean solution currently. We don't have a 
way to define listeners in the registry atm, we could loop through all 
APIs and check for certain methods  though. Like we do for 
clearUserData or admin_list already.

Updated patch file attached, merged with current HEAD. Should be clean 
(I hope). Thanks for all the feedback.



Let me know if you think I should pursue the passwd application 
integration concept.



I will be looking at IMP next to secure the credentials for remote 
email systems.

Never mind on my first question - figured it out (yikes!).



Still wondering if a password change hook makes sense. I would need to 
find some way to register all such encrypted values to keep track of 
what needs to be updated with the new password-based encryption key.

I'm OK with using the user's password as a key. However, I couldn't 
tell at first glance whether it is available in plain text after it 
has been stored in the session. If you know where I should look, let 
me know. Otherwise I'll dig a little deeper on my own and get back to 
you.



So next question - should I try to integrate with the password change 
application to re-encrypt a value when I have both the new and old 
passwords? It's still not bullet-proof, because passwords can be 
changed outside of Horde. Perhaps it's not worth the extra 
effort...thoughts?

No, and this is *not* a support forum.

Hi there.

I am new to horde an dkronolith and still testing.

With kronolith, I have a calendar with users, groups and rights. I 
have edited them to have only rights to view or show. They still have 
the right to write new events , edit and kill'em. They should not have.

Is this the same problem you are talking about ?

I want to be admin with editing events. The users only may see the events.

How to do ?

Do I have to change the php and delete the lines for showing the buttons ?

Any help would be great.

Is there any german forum ?

Yours sincerely, Jörg Heusler

Why don't you use the users current password as the key? Granted, this 
will still break decryption if the user changes his password, but it 
makes a perfect secret key. I could have sworn we do this already 
somewhere in the code, but I can't find where.
Sure.

OK - no problem. I wanted to obfuscate the value in the database 
without hard-wiring any magic cookies in the code. However, I agree 
it's not particularly secure, and we can make it a bit stronger by 
separating the key from the encrypted value.



As an (imperfect) alternative, I could add a configuration parameter 
in the Horde setup for a global encryption key, optionally generating 
a random value for a new Horde installation where no key exists. If 
this makes sense, I can also declare a new setup configuration tab to 
define shared encryption parameters (key, key strength, algorithm, 
etc.).  I can then plug these parameters into the Secret class.  I 
will also add some convenience methods for the Base64 string wrapper.



I'll put together a fresh patch with these additional changes for your 
review. I'm also open to other suggestions. Do yo think this same 
approach would work to protect the IMP fetch mail credentials?



Thanks,

Tom

Ah, not quite. This patch doesn't give any more security than storing 
the credentials in cleartext. You use a known key (the url, stored in 
clear text in the preferences) to encrypt the credentials. Anybody who 
has access to the preferences, the people your are trying to protect 
the credentials against, can easily decrypt them, because they have 
the key. It's a bit more work, but still easy.

No, should be fine then, thanks for testing.

OK - I cleared all cookies, dropped the session, log on/off and still 
have a good remote calendar connection.  Thanks for the feedback. 
Anything else?

Yes, try deleting cookies.

I have successfully connected with authenticated remote calendars 
across multiple login/logout cycles and everything seems fine. I also 
manually cleared the Horde cache and session files on the server just 
to be sure.  Any other conditions I should test?

I'm wondering if that really works? If I remember correctly, secrets 
are only guaranteed to work during a session, so you might be unable 
to decrypt the credentials after logging out.

Per my note to the dev list, this patch adds HTTP authentication 
support for remote calendars.



- The "Remote Calendars" prefs page was changed to accept 
user/password inputs, and to allow editing of an existing remote 
calendar entry

- The "My Calendars" page was updated to add an iCal link to each 
calendar to provide a convenient way to copy the corresponding URL

- The lib/prefs.php code was updated to handle the new preference attributes

- The lib/Kronolith.php class was updated to look up the user/password 
as needed



Note that both the user and password are encrypted and wrapped in 
base64 to prevent inadvertent disclosure via database queries. The 
encryption key (an MD5 hash of the target URL) is not particularly 
strong, but it is convenient and it should be sufficient to keep most 
DBAs honest.



Tom Evans

Tachometry