View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001064||SOGo||Web Preferences||public||2010-12-28 17:24||2011-07-06 20:46|
|Summary||0001064: SOGoMailAuxiliaryUserAccountsEnabled stores passwords in plaintext|
When using the SOGoMailAuxiliaryUserAccountsEnabled feature, the IMAP password is stored in the sql database in plaintext. Ideally the admin could set that password can never set and then the webmail user must provide the password(s) on trying to connect to those remote server IMAPs. If the admin doesn't restrict this, then users have the option of providing a password which is stored with some hash on it.
Also: maybe in the bug tracking system could have a label of "security" under severity?
|Tags||No tags attached.|
The user could not provide a hash himself for storing such passwords.
When SOGoMailAuxiliaryUserAccountsEnabled, we could enforce the administrator to also set a hash, say:
SOGoMailAuxiliaryHashString = "deadbeef";
and all stored password would be hashed (XOR) with it. While if someone steals the database he couldn't do anything with the hashed password (beside brute forcing them), the security wouldn't be improved that much because if your database is compromised, that hash string would likely be exposed too.
I disagree: the SQL server may be on a different machine than the SOGo server there are many situations where the DB could be hacked (SQL injection, etc) where the filesystem / sogo user account on the server running SOGo has not been compromised. Additionally, the SQL server may have a backup / archive that could be compromised without having the SOGoMailAuxiliaryHashString being accessible.