Our Security

by | Jun 2, 2017 | Security

Our Security

You often hear that companies care about security, or have it baked into their design. That is often simply not true – or the things they are willing to do are limited to what modern website architecture give you naturally. Unlike those sites, we know exactly how to defend against the most common attacks, and we recognize how important this is for your business. Our security is your security, and we know that failure simply isn’t an option. So we’ve gone far above and beyond. Here is just a sampling of what we do to protect you. If you have any additional questions about how we handle you and your company’s data, please contact support.

SSL/TLS/x509:

  • User Administration requires 2048 bit RSA SSH keys which makes them highly resistant to brute force.
  • We set the Strict Transport Security header which enforces that users’ browser always connect over HTTPS.
  • All accounts data is sent to our servers with SSL/TLS.
  • We have an A+ rating on SSL Labs.
  • We leverage HSTS Preload to further prevent man-in-the-middle downgrade attacks.

Password requirements

  • Our password policy requires a minimum of 8 characters, one special character and one number.
  • We validate against a large list (approximately 14 million) of known compromised passwords to ensure our users aren’t re-using known bad/hacked passwords.
  • All passwords are stored in a bcrypt format with unique salts. Each hash requires approximately 1 second in computer-work-effort per attempt which is double industry norm/default. As such, the passwords are only known to us in hashed form. If we were ever compromised, our users passwords would be very difficult to crack as a result.
  • The database is not publicly accessible on any ports, and has an extremely long random password.
  • Our administrative system user accounts use extremely long bit-length RSA keys.

XSS Protection

  • Default libraries neuter dangerous information before it is stored in the database.
  • The optional X-XSS-Protection header is set to block in Internet Explorer, instead of attempting to neuter attacks, which provides higher levels of security.
  • The optional Content Security Policy headers are set to allow only our vendors and ourselves to be included on the page. It also neuters inline JavaScript to limit injected JavaScript on all authenticated pages.
  • The optional X-Content-Type-Options header is set to “nosniff” which means the browser will not guess what kind of data is being returned, which enforces that each of the pages are properly rendered only when the correct header is present on all authenticated pages.

CSRF Protection

  • Nonces are generated per account and per authentication token on all sensitive functions. The nonces are 64 digit, hexadecimal strings giving them an entropy of 2^256 (approximately 1×10^77). Current best practice is 2^128 (approximately 3×10^38).

Clickjacking Protection

  • The site utilizes the optional X-Frame-Options header which prevents the site from being framed by an adversarial domain.

Command Injection

  • We do not ever pass user based content to system shell commands.  All of our web-facing server-side code is written in native Python.

SQL Injection

  • All user input is sanitized prior to entering it into the database.
  • All database entry points are parameterized to prevent malicious code from breaking out of SQL commands.

Cookies

  • All account authentication attempts, successes and account changes are logged.
  • Cookies are set per user and last up to 30 days and are disabled by both server and browser logic upon expiration.
  • The cookies are 64 digit, hexadecimal strings giving them an entropy of 2^256 (approximately 1×10^77). Current best practice is 2^128 (approximately 3×10^38).
  • We set the Secure flag on all of our cookies to prevent Man in the Middle attacks from downgrading SSL/TLS and reading the cookies once set.
  • We set the HTTPOnly flag on all cookies to prevent them from being read by malicious JavaScript.
  • We don’t allow authentication cookies to be read by any pages outside of the application.

Use of 2nd Factor Authentication

  • We require use of 2nd Factor Authentication on our CDN provider.
  • We require use of 2nd Factor Authentication on our DNS/Domain provider.
  • We require use of 2nd Factor Authentication on our payment provider.
  • We require use of 2nd Factor Authentication on our trouble ticketing system.
  • We require use of 2nd Factor Authentication on our email distribution system.
  • We require use of 2nd Factor Authentication on our administrative web accounts.
  • We require use of 2nd Factor Authentication on our blog’s administrative accounts.
  • Second Factor Authentication can optionally be enabled on a per-account basis – we do recommend this to prevent brute force attacks and password re-use attacks.

Credit Cards:

  • We do not have or store actual credit card information.
  • We maintain only a token which is known to us in reference to the card on file with our payment provider.

HR personally identifiable information:

  • We intentionally ask that our users do not upload names, addresses, phone numbers, social security numbers all which might give away personal information.
  • We allow our users to delete any information that may have inadvertently be uploaded before a formal audit is conducted.
  • All information is purged from the system once a user account has been deleted.

Software updates:

  • The primary and test systems are updated and patched for security vulnerabilities on at least a weekly basis.