Have a question about security?

Found a flaw in Cypht? We want to hear from you!

Drop by the Cypht Gitter channel, or send me an E-mail at jason@cypht.org. 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