Have a question about security?
Found a flaw in Cypht? We want to hear from you!
Drop by the Cypht Gitter channel. We take security seriously. Cypht is an entirely volunteer effort, so we can't afford a bounty program. We can however promise that any security issue reported to us before release will receive a quick response, a thorough review, a sincere thanks, and an honorable mention on this page
In the browser
- By default all cookies are session level, HTTP only, and have the secure flag, path, and domain values set (except one cookie used to pass user notices to the javascript)
- HTTP request header fingerprinting, CSRF token protection, and target/source origin mismatch blocking
- Security related HTTP headers like X-XSS-Protection, X-Content-Type-Options, X-Frame-Options, and Content-Security-Policy
- Subresource Integrity for the 2 primary includes (site.js and site.css)
- Configurable idle timeout module set that ends a session after a predetermined amount of time
- Support for 2 factor authentication with any TOTP compatible authentication application
- Optional AES encrypted AJAX responses
- Optional AES encrypted local session storage cache
- reCAPTCHA support for the login form
On the server
- TLS/STARTTLS support for IMAP, LDAP, and SMTP connections
- Oauth2 over IMAP/SMTP supported (currently only Gmail and Outlook support this feature)
- Session level data is encrypted with a long random string generated on login. Data is stored server side, and the key is stored in a session level secure cookie
- Persistent data stored between logins is encrypted with a key derived from your clear text password, which is obviously not stored anywhere
- All encryption is done with libsodium if available, otherwise with AES-256-CBC, encrypt-then-MAC, and PBKDF2 key derivation using OpenSSL (NOT Mcrypt)
- PHP ini settings are tightened up at runtime for extra security, including open basedir and session best practices (ones writable at runtime)
- No writable files or directories are used inside the web-server document root, and only 3 files need to be inside the document root to run the program. Module sets may include additional assets, such as the HTML editor for outbound mail
- Optional local DB based authentication using a salt and PBKDF2 (or libsodium using Argon2 if available)
- HTML formatted E-Mail is filtered through HTMLPurifier with all external resources removed before being rendered
- Perfect score from the "Email Privacy Tester" at https://emailprivacytester.com/
During development
- Easy output escaping inside modules for potentially dangerous content
- Development is done with PHP's "E_ALL" and "E_STRICT" error reporting
- Module design enforces a separation of input processing and output formatting, and encourages concise methods, which makes the code easier to debug and audit
- Only white-listed and typed/sanitized input is allowed. Modules must pre-define input in order to have access
- Modules can't reference PHP super-globals, and there are no globally scoped variables at all (there are a few static class instances with private data structures that use getter/setter methods)
- ~98% unit test coverage with PHPUnit for the application framework and core module set
- UI tests using Selenium with python bindings (currently at 64 tests)
- Continuous Integration for UI tests, unit tests, and static code analysis done with Travis CI. You can read more info about our testing process at the testing page