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.
Why does DocuSign require that your password "must not contain the characters <, > or spaces."?
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.
- 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.
- 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).
- 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.
- 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.
- 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).
- 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.
41+1. Excellent answer, as usual. I should be allowed to make my password
' UNION SELECT username, password FROM users--without any adverse effects.– mti2935Oct 24, 2021 at 0:56
2Re 1, I could think of a (pre-ajax) signup form that tells you the username is already taken but otherwise preserves all the input values.– BergiOct 24, 2021 at 3:39
4Beyond XSS, there may be other backend processing reasons for limiting characters in passwords (eg., having to route through an old system or poorly-implemented XML parser). They're not good reasons, in this day and age, but XSS isn't the only possible concern. Also, some web servers block POSTs with characters that look HTML-ey, which may be an issue here, too.– minnmassOct 24, 2021 at 6:58
3@minnmass You really shouldn't be routing the plaintext password through anything except a load balancer, which just forwards the request as HTTP without parsing the body anyhow. On the other hand, even if you do need to make the plaintext password XML-safe for some $DEITY-forsaken reason, that's easy to do client-side by encoding XML metacharacters on whatever server is stuffing the unhashed password into XML. Seriously though, if that's a relevant question, you've screwed up badly somewhere. Oct 24, 2021 at 22:49
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:
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.
10Bletch. Pitch that WAP into the abyss. It cannot function.– JoshuaOct 24, 2021 at 20:30
4I remember we had an issue like that with a firewall at a customer's. This was a nightmare to debug and understand: most requests were fine, but occasionally 1 request would be transmitted with an empty body (IIRC) and no indication of what happened. It's only when we finally managed to capture such a request and resend it that we were able to pinpoint it to the firewall.– Didier LOct 25, 2021 at 14:14
2This is an interesting idea. Assuming there is some intermediate layer between the browser and the server that is outside their control and blocks requests containing "suspicious characters", wouldn't it make more sense to client-side encode the password into an acceptable character set, transmit it safely through the nanny layer, decode it on the server, and carry on as normal?– emoryOct 25, 2021 at 20:56
2@emory That's definitely a more robust approach, but it's a lot more work than just banning a few rarely-used characters from passwords.– IMSoPOct 25, 2021 at 21:33
1@IMSoP Rarely used by people who don't use password generators...which is a sad state for developers (or really any computer professionals) to be in. Oct 26, 2021 at 15:28
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?
7On the other hand, this has become a signalling mechanism. If you definitely trapdoor-function all incoming passwords there's no reason to restrict characters. Thus, this screams at engineers "I store passwords plaintext."– JoshuaOct 24, 2021 at 20:29
5Maybe it's a red herring to make hackers waste their time on attack vectors which won't work ;) Oct 25, 2021 at 2:00
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.
12I want to correct that to Bobby Tables, but then "Bobby Tales" probably accurately reflects their level of understanding and familiarity with these attacks.– muruOct 24, 2021 at 16:30
5Presence of security theater does at the very least imply that someone with executive authority in the decision-making process doesn't understand the distinction between security theater and actual security and/or declined to listen to anyone who tried to explain it, so it's generally not a good sign.– ShadurOct 25, 2021 at 10:39
2Also if they're willing to engage in security theatre while at the same time having solid security, they should be aware that their security theatre will make them look foolish to anyone who knows that blocking angle brackets in passwords would only be necessary in an insecure system. That should be a bigger concern for them than providing false reassurance for people who don't really understand - people who could reassure themselves by trying angle brackets and finding they don't cause any harm?– NiallOct 25, 2021 at 10:44
1"But if they removed the restriction, that would also be security theater." How do you figure? That would legitimately increase security, by increasing the number of possible passwords. Oct 25, 2021 at 21:06
2@emory You're underestimating the effect of my mental curses condemning these people to a painful afterlife--as I have to manually adjust the password generated by my password generator in order to make it acceptable to this website (and then manually copy it back into my secure password storage, being careful at every step). They're getting off lightly since at least they've listed the forbidden characters, but even so, I wouldn't want to risk it personally. Oct 26, 2021 at 15:33
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.
7What command line are you thinking of? Your usual Unix-like shell would have way more special characters than just those two (
\;&|()$"'etc.). Windows probably too.– ilkkachuOct 24, 2021 at 19:51
3Passwords should never be passed on the command line anyhow. Command lines are public -- readable by other users. If someone considers "it should be easy to pass these on the command line" as a goal, they've failed security awareness 101. Oct 25, 2021 at 0:40
1I can not imagine a highly usable web application needing passwords to go through the command line. A more likely scenario is that some users will write their passwords on paper. Then spaces can be especially problematic. Things like I, l, 1 are also problems. If a lot of your users are writing down passwords and this character confusion is getting in your way, it might be best to disallow those problem characters.– emoryOct 25, 2021 at 21:22
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.
&in your password?
>looks to me like a restriction found during testing; it suggests that the programmers were ignorant about XML and the testers found a bug that they decided to document rather than fix. In that situation my guess would be that the testers failed to discover that
&also causes problems.