Release cycle
Due to the impact of this release, i will not publish fast rolling releases the next two months.
Only important bugfixes will be published to make everything very stable.
Vulnerability
I found a security vulnerability in the accounts management.
The data was encrypted using the SALT that is on the server.
This means anyone/anything that has access to the SALT could decode the accounts and gain the passphrases.
Detailed info reported at RainLoop#2134
This release has several solutions to this problem and workarounds:
- Support is added to encrypt using Sodium (when available) else OpenSSL (when available) else the old broken XXTEA.
- Additional accounts are not \RainLoop\Model\Account but a child \RainLoop\Model\AdditionalAccount
- The AdditionalAccount passphrases will be encrypted using a key that is based on the MainAccount login passphrase (with option to set own CryptKey by plugins)
- When MainAccount gets a new passphrase, switching to AdditionalAccount is impossible due to the changed CryptKey
- System will now show error and popup the "edit account" window to re-enter the passphrase (will also happen when child account passphrase is changed)
- MainAccount will not be stored on server with the additional accounts (it does in RainLoop)
- Contacts sync has same issue and is now also encrypted using CryptKey
There are now two cookies:
- MainAccount cookie
- optionally the switched AdditionalAccount cookie.
This way the MainAccount is always properly accessible when working in an additional account.
Logout will destroy both cookies.
Switching from child to main account will destroy the AdditionalAccount cookie.
Both cookies are encrypted using a nonce/iv/salt that is stored in the cookie.
The cookies encryption key is based on your user agent header and salt (i know this is an issue with Tor and certain firewalls, empty string fallback is the server SALT).
Overall, with Sodium on my server the Lighthouse page speed dropped from 99% to 98% due to a 20ms increase for the better encryption methods.
This impact differs per server setup.
Other solutions i thought about but didn't pass:
- Separate passphrase for the additional accounts and Contacts sync (but then at login you need to enter a second passphrase).
- Browser stored data (defeats the purpose of login with several devices, only 1 device has the data, just like the previous "remember me" bug).
- WebAuthn support not great and easy
- openssl_seal to allow multiple people having a key to open them needs management to add new people to the list. But when you loose your key, you will not have access.
- store as METADATA in the IMAP, but relies on METADATA support of the server.
Vulnerability impact
Although the system may attempt to fix and update the files, it will NOT try an attempt when there is no login on an account (because password is unknown).
When update fails, it should not loose the accounts
Future
In the future i might change the system a bit by using a CryptKey file.
That file will store the encryption key to decode the additional accounts and contact sync.
This way, if there are many additional accounts and contact sync, the user only has to update the CryptKey file password and not update every additional account.
I waited with this approach because it impacts the system with another login screen to ask for the old password (which is strange behavior in a UX sense).
Bugfixes
- system folders initialization failed on first time login
- iSpamScore should be int, not float
- CSS removed bootstrap .clearfix (old "fix" for float stuff)
- CSS removed bootstrap .well and .pull-left
- Remote.message() and Remote.messageList() RawKey mode broken, fixed using JSON
Improvements
- Added encryption using OpenSSL (default: aes-256-cbc-hmac-sha1)
- Added encryption using sodium_crypto_aead_xchacha20poly1305_ietf_*
- Don't decode Account cookie several times (1x decrypt is enough)
- Try to convert the old less secure accounts and sorted order to the new encrypted ones at login
- When switching to additional account fails, show account update screen