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