[WSSMAIL-7] Add ability for zero-trust type authentication

← All Issues || New Issue →

Sort Normal || Priority

Details

Current webmail applications have a lot of trust put in them by their users, who directly provide their IMAP/SMTP usernames and passwords to the webmail application. Doesn't matter if the webmail application and mail server are operated by the same entity (think Gmail.com), but more so if the webmail application is completely separated and operated by a third-party that is neither the end user nor the mail server. This is the case for some users of wssmail, who use this application as an alternative to the native webmail interfaces for mail servers that are not very accessible for some clients.

Currently, these users are forced to trust us with their username and password and hope nothing goes wrong. Prior modifications made it so the server doesn't even store this information directly; this information is sent by the client as needed so mail server credentials are never stored at rest by the server (and are only stored encrypted by the client). However, at some point, they are processed by the server. The user just has to trust the application isn't malicious to some extent, and while we aren't, it would be great to do even better and have mechanisms that don't require the server ever seeing the plaintext credentials at all.

• For example, PAKE (Password authenticated key agreement) is an interesting concept here.
• CRAM-MD5 is also interesting since it allows digest authentication. Unfortunately, it requires the server storing the plaintext password, which is not a good property. Otherwise, it would be great since challenge-response is an excellent approach for this kind of application.
• OAUTH2 support will become more important as more major mail providers continue to make basic authentication harder to use, resulting in projects like this: https://github.com/simonrob/email-oauth2-proxy - it would be neat if the OAuth2 transaction process could be implemented in some kind of low/no-trust manner here.
• If connecting to an LBBS mail server, the user's .imapremote can contain credentials for other mail servers, allowing a single webmail session to access many IMAP servers at once. However, not every user may be comfortable putting their mail server credentials on a file in plain text that is permanently stored on the BBS (even if it's private in their home directory - maybe they don't trust the sysop!) A nice enhancement would be to have the ability to store this information locally on the client and send it on demand over the Websocket connection to the LBBS server, which can on the fly apply this for that particular connection. Similar to how password authentication is done now. This means none of this information is ever stored permanently by the mail server, and a sysop would have to be more intentionally malicious to intercept credentials.

Comments

You must be logged in to leave a comment.