On 10-12-28 7:09 PM, Jan-Frode Myklebust wrote:
OK, guess I don't understand the details well enough..,
I think you do understand enough - but what I described what the current
behavior and what we could do without changing things too much.
it just feels so bad to store plaintext passwords anywhere. My assumption was
that when
SOGo needs the password for IMAP, it could either be generated by via
the "secured session cookies" or for non-cookie-based authentication it
would be provided in plaintext (basic auth) from the client.
We basically have four scenarios :
1- proxy authentication (mainly for WebAuth) - where SOGo wouldn't have
the password nor need it because the IMAP server would trust SOGo (ie.,
accept any password it receives from SOGo)
2- CAS authentication - much like 1, SOGo doesn't need the password as
the IMAP server needs to be CAS'ified too
3- "Web" (cookie-based) authentication - we now have a the "secured
session cookies" from which we can deduce the password using the session
key and user key
4- "DAV" (basic auth, used by Lightning, iCal, Apple iPhone, etc.)
authentication - which provides the cleartext password upon each request
and thus, is trivially deduced
For 3 and 4, we could as you suggested store a SHA (or whatever) version
of the cleartext password in memcached that we would have got during the
very first call and then, upon subsequent calls, compute again the
deduced value and compare those hashes instead of going to the LDAP
server (or SQL server if using SQL-based authentication).
If the action the user initiated requires the cleartext password (for
example, to log in on the IMAP server), we can easily get it through the
authenticator but that one isn't stored in memcached.
Regards,
--
Ludovic Marcotte
[email protected] :: +1.514.755.3630 :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
--
[email protected]
https://inverse.ca/sogo/lists
