Why does DocuSign require that your password "must not contain the characters <, > or spaces."?

Question

DocuSign requires that your password "must not contain the characters <, > or spaces." Is this not an odd requirement? Despite being a leader in online document signing, my gut tells me there's something odd under-the-hood.

Answer 1

Generously? Because that restriction was created by somebody with no understanding of web security. (Less-generous possible explanations are up to the reader.)

The typical danger in such characters is if they're ever output into the response, in which case they could lead to XSS. However, that shouldn't ever be a problem, for so many reasons.

1. Foremost, passwords in general should literally never be in responses. There's just no situation where a user-specified password should ever be present in any content returned from a server.
2. It shouldn't even be possible to do this; the server should not store the password (even in memory) for any longer than is needed to verify its quality and then hash it. If the quality check (which can be done every time, or only at password creation/rotation) fails, you still should immediately forget what it was (and definitely shouldn't return it, see #1).
3. Passwords should only ever be persisted in the form of digests from salted and expensive hashing functions. Hash digests won't contain those characters (under any likely encoding), shouldn't ever be put in responses either, and having those characters in the input is irrelevant to the digest anyhow.
4. Even if, for some security-forsaken reason, you wanted to return a password in a response, you should apply standard anti-XSS measures to it, like output encoding. This applies to all user input that ends up in responses. You could also return the value in an API response and have client-side code inject it as text (this is what e.g. React does), which is also safe.
5. XSS is generally only relevant if an attacker can force somebody else to visit the page. Since a login page isn't going to reflect any other user's stored data back, and certainly shouldn't do anything with taking a password from the URL and putting it in the DOM client-side, the only approach that would make sense is reflected XSS. It's easy (though admittedly uncommon) to prevent third parties from attempting to submit a password on behalf of another browser; that's what anti-CSRF methods do (login CSRF is generally not treated as a big risk, but in the specific case of DocuSign it actually might be, if somebody uploads a confidential form to what they think is their account but actually isn't, so hopefully they are protecting against that).
6. There are other mitigations against XSS, such as Content Security Policy. With nearly all browsing activity now on browsers that support it, and with login pages being security-critical and generally lacking third-party content, they're an easy and obvious place to get a lot of protection from CSP.

Beyond all the reasons why you shouldn't need to have such restrictions, they look extremely sketchy. They imply that passwords might ever end up in responses and/or that they're being stored in plain text (in the database, or in logs which is arguably even worse).

As a practical matter, preventing those few characters doesn't meaningfully impact the security of available passwords (that is, nobody is likely to have a password that would be safe if only it could contain a <, but isn't otherwise), nor does it significantly simplify brute-forcing attacks. However, it still reflects poorly on the security awareness of the site.

---

EDIT: As pointed out in the comments, it's possible the problem is instead that the unhashed passwords are - or were at some point - being put into another context that cares about angle brackets, such as an XML document (stored or transmitted). Obviously this breaks several of the guidelines above, such as doing anything with the password other than validating, hashing, and forgetting it, but also it's easily addressed; as with reflecting the password into HTML, if it's put into XML, it should be output encoded first.

Answer 2

Only DocuSign can give you the definitive answer, but one plausible explanation for the angle brackets is that they have generated a false positive in a security tool.

For example, many applications run behind a Web Application Firewall (WAF). These examine the traffic between the user and website for any suspicious activity. Let's say a user wanted to make their password:

<script src=https://example.com/Evil1.js></script>

It's a bit of a strange thing to use as a password, but it would pass most of the usual checks: long, mixture of character types and not commonly used. As a password it is also totally safe, for the reasons given in CBHacking's answer.

However, a WAF has no understanding of the application it is protecting. From the WAF's point of view you might be about to display the value straight back to the user. If you did that it would be a security vulnerability, so the WAF blocks the request. Again, the WAF isn't really integrated into the application, so the user inputting that password would probably just get a generic error page with no explanation of the error. Worse, the WAF might only protect some parts of the application - e.g. you might see the error when you log in from a mobile phone, but not when you set your password from the desktop.

The software generating the errors might not even be under DocuSign's control - it could be something they've become aware of because it was installed across the corporate network of one of their customers.

From a customer service point of view, it is better and easier to forbid use of two characters, than to support users who encounter these errors.

Answer 3

This is likely just playing safe. Such characters are commonly used in injection attacks like XSS. While they probable try to keep such bugs out of their system, perfection is not possible. So disallowing such characters is a kind of defense in depth.

With passwords one can probably live with this. In other places this kind can be more annoying or even unexpectedly impact functionality - see Is single quote filtering nonsense?

Answer 4

It is possible to come up with sinister explanations. There are is also at least one benign explanation.

There may be a non-trivial number of users who while not being highly technically inclined are familiar with the Bobby Tales attacks. Obviously no one would want to use a product that is vulnerable to the Bobby Tales attack. They have to convince their users in one way or the other that they are not vulnerable. (This is a separate but related task to not being vulnerable.)

Perhaps for some users, the easiest way to do that is just to ban those characters.

The downside is that certain other users will see this as "security theater" - which it is. There seems to be an impression that the presence of security theater implies the absence of security. This is not true, but a lot of people believe it.

Answer 5

All the current answers assume there is a (bad) security reason for the limitation but it may also be just a matter of usability.

When you want to sign a document with a password using command line functions it becomes very inconvenient if the password has '<' or '>' characters.

Spaces in a password can undesirable because users accidentality include a space when using copy/paste from their password manager. When you forbid spaces in the password you can strip them before verifying.

Answer 6

While the answers here are good, and I can only speculate on why DocuSign has those requirements, there's a common issue that I don't see listed in the current answers.

Upstream Password Complexity Issues

Many existing systems have password requirements for technical or logistical reasons outlined by the other answers, in order to support these systems in a downstream system you have to enforce a "most limited" password strategy. That is, a strategy that works for all upstream systems.

For example, I used a system where the default binding for Shift+6 '^' for an IBM iSeries AS400 terminal emulator (5250 terminal) was actually '¢'. If your password was set by an automated system to '^' you couldn't login via the terminal that was bound to '¢'. If you reset your password via the terminal ('¢'), you couldn't login via the outside systems ('^').

The result was, we asked users not to use Shift+6 in their passwords.

I've seen this many times over in multi-tiered systems where certain technology in the dependency chain had odd password complexity requirements. These outliers set the standard for every connected system. It may be possible that DocuSign built or acquired a system that doesn't handle the mentioned symbols—thus restricting their use.