While the lack of a CSRF token means an attacker can trick a user into logging out of their Whatbox account, we consider this a non-issue.

1. A cross site logout increases the security of the user, by restricting the potential for further exploit.
2. If CSRF tokens were employed, an expired token could prevent a user from logging out successfully and accidentally leaving a valid session open when they intentionally clicked "Logout".

Due to the requirements for unique usernames and unique email addresses, username enumeration is possible in many areas of the site. We employ rate limiting to limit the volume of information that can be leaked this way.

We do not consider this a real vulnerability.

An attacker cannot make a victim's browser submit an invalid Host header without directly controlling the browser / computer which forms the trusted computing base for a website. If the attacker already has this much control, no counter-measure can keep a potential victim safe.

Some researchers have pointed out that some websites use the Host value in generated page content. We don't use the Host value in our code, preferring domain relative URLs (eg. /preferences).

Unless you can construct a HTML proof of concept that triggers this in an unmodified web browser, we will reject all reports of this type.

This is more subjective than most of our security choices. The composition of passwords has been an ongoing debate for several years, and we fall into the camp that believes in allowing as many types of passwords as possible.

People don't want the cognitive load of remembering more complex passwords, so if you require lower + upper + number they will change their password from "password" to "Password1" which is not much better.

A password that consists entirely of lowercase letters or only numbers can still be stronger (more entropy) than one with uppercase letters, symbols, etc. simply due to length. Passwords of any length can also be useless if they're reused across many websites and become known to an attacker.

We have experimented with the haveibeenpwned API in the past. This denylist can catch all passwords known to attackers (and would statistically block all the easy ones like "123456"). Unfortunately, we have refrained from deploying this because people find it upsetting when you tell them their password is known to blackhat attackers.

For some of the discussions we've watched over the years:

• Short complex password, or long dictionary passphrase?
• Are password complexity rules counterproductive?

We feel the best hope for the future of password security is built-in browser password managers, like Chrome's efforts to generate unique random passwords for every website.

We also intend to implement biometric based logins for supported devices, helping users use strong, unique identifiers with minimal cognitive load.

An account that nobody knows the password to is the most secure of all, but it's not very useful to anyone. We need to balance the need for high entropy unique passwords against unreliable human memory.

DNSSEC has been on our radar for several years, but we remain concerned about the impact on reliability.

DNSSEC looks like a "footgun" to us.

Similar to HTTP Public-Key-Pinning before it, it does provide a security improvement, but has a very unforgiving implementation where the slightest human error can cause outages that are impossible to resolve. There's no "undo" with DNSSEC, and it frequently brings major domains offline for weeks at a time.

We intend to wait this one out several more years. I believe either DNSSEC will be replaced by a v2 that addresses some of the pitfalls or the combined experience of many engineers across many organizations will create a well documented set of best practices we can follow.

Citation: An incomplete list of major outages caused by DNSSEC.