58

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.

carrier
  • 633
  • 2
  • 7
  • 19
    Many of these "requirements" are made by programmers, not security experts. They read somewhere that these "can be dangerous" and just decide to disallow them. –  Oct 23 '21 at 16:25
  • Related: https://security.stackexchange.com/questions/17192/why-disallow-special-characters-in-a-password – mti2935 Oct 23 '21 at 22:27
  • 121
    maybe all the passwords are stored in a giant XML file – Strikegently Oct 24 '21 at 01:19
  • Related: https://security.stackexchange.com/questions/111809/ – John Deters Oct 24 '21 at 03:26
  • 4
    @Strikegently, but they still allow you to have `&` in your password? – Toby Speight Oct 24 '21 at 12:07
  • It's a matter of effort vs value. Incredibly easy to disallow certain characters, and the benefit of preventing even 1 incident is many times greater than the cost of disallowing those characters. – Issel Oct 25 '21 at 08:19
  • @strikegently may have it and I for one would be *extremely concerned* at any error warning that those characters are illegal. – Shadur Oct 25 '21 at 10:34
  • I wonder if the problem is not the characters per se but the keystrokes - e.g. is there a browser in which pressing "<", ">", or space will move the cursor into the next (or previous) text field, and leave the user typing the second half of their password into a field that's not designed to contain something secret? – Daniel Hatton Oct 25 '21 at 20:27
  • 2
    @TobySpeight the requirement not to include `<` and `>` 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. – Michael Kay Oct 25 '21 at 21:18
  • 3
    Mandatory xkcd: [Little Bobby Tables](https://xkcd.com/327/). – Peter - Reinstate Monica Oct 26 '21 at 05:51

6 Answers6

101

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.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • 41
    +1. Excellent answer, as usual. I should be allowed to make my password `' UNION SELECT username, password FROM users-- ` without any adverse effects. – mti2935 Oct 24 '21 at 00:56
  • 2
    Re 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. – Bergi Oct 24 '21 at 03:39
  • 4
    Beyond 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. – minnmass Oct 24 '21 at 06:58
  • 9
    +1 @mti2935 no I should be allowed `\`CBHacking'); DROP TABLE users;--`, [xkcd 327](https://xkcd.com/327/) – kelalaka Oct 24 '21 at 21:36
  • People are obsessed with such delimiters being used in attacks, but the could also just cause errors in parsing. Docusign is more than a "site". Restrictions on characters (but not normally these) can also indicate multiple platforms or SSO being in use. It is far more likely that the password needs to be tokenised before being hashed, and that the tokens are delimited by <> . I am not game to try a tab. (3 years as User). – mckenzm Oct 24 '21 at 22:30
  • 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. – CBHacking Oct 24 '21 at 22:49
  • 1
    @Bergi Aside from the thing where pre-AJAX means you're designing for a browser from the early 2000s or before (IE5 supported AJAX, so yikes!), it makes more sense to set up the email address and password at one time, and then make username a separate request. In any case, even if you were in that situation, you still shouldn't reflect the password. (Also you're using SSLv3 at best, so please don't actually do anything authenticated whatsoever...) – CBHacking Oct 24 '21 at 22:59
  • 1
    @CBHacking I just meant a form where validation doesn't occur using AJAX. These still exist… You're right, a multi-step process where the password is the last part would be nicer, but I still don't see anything wrong with reflecting a password back to where it came from. – Bergi Oct 24 '21 at 23:14
  • @CBHacking I agree; I’m just pointing out that “prevent XSS” isn’t the sole reason brackets might be blocked. – minnmass Oct 24 '21 at 23:22
  • 2
    This reminds me of an ancient safeguard in .NET WebForms which prevented `<` and `>` (and a few other characters I think) in ANY `POST` field. It was a filter before any other processing took place. Of course, this was from the early days of the web, and this day and age there is no valid reason for having something like that. – Vilx- Oct 25 '21 at 08:44
  • 1
    @kelalaka: I prefer `'; DELETE FROM users WHERE RANDOM() % 251 = 0; --`. Makes things a bit more challenging for the server's maintainer. – dan04 Oct 26 '21 at 22:29
  • @CBHacking Even assuming all of your VERY GOOD points here are ignored, even in the halcyon days of the 1990s in which some of these things were somewhat valid reasons, we still had base64 in widespread use to work around this exact challenge. So really and truly, there is no excuse. – Iron Gremlin Oct 26 '21 at 22:48
31

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.

thelem
  • 1,016
  • 8
  • 6
  • 10
    Bletch. Pitch that WAP into the abyss. It cannot function. – Joshua Oct 24 '21 at 20:30
  • 4
    I 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 L Oct 25 '21 at 14:14
  • 2
    This 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? – emory Oct 25 '21 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. – IMSoP Oct 25 '21 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. – user3067860 Oct 26 '21 at 15:28
6

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?

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 7
    On 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." – Joshua Oct 24 '21 at 20:29
  • 5
    Maybe it's a red herring to make hackers waste their time on attack vectors which won't work ;) – Turksarama Oct 25 '21 at 02:00
2

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.

emory
  • 1,560
  • 11
  • 14
  • 12
    I want to correct that to [Bobby Tables](https://xkcd.com/327/), but then "Bobby Tales" probably accurately reflects their level of understanding and familiarity with these attacks. – muru Oct 24 '21 at 16:30
  • @muru you are correct that I made an error. nonetheless I will leave it as is for the exact reason you pointed out. – emory Oct 24 '21 at 16:39
  • "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." Sure, it's not guaranteed to be true, but you have to admit there's a very strong correlation. – Joseph Sible-Reinstate Monica Oct 24 '21 at 22:03
  • 5
    Presence 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. – Shadur Oct 25 '21 at 10:39
  • None of the characters in the "bobby tables" example are even angle brackets. They'd need to block a lot of characters other than <> to protect against SQL injection. If they haven't blocked SQL injection characters but have blocked XML/HTML special characters, then their "security theatre" is designed to suggest they're not vulnerable to XSS issues rather than SQL injection. Are there many users familiar with XSS who would be convinced that passwords should be checked for special characters? I'm not sure this theory holds much weight. – Niall Oct 25 '21 at 10:40
  • 2
    Also 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? – Niall Oct 25 '21 at 10:44
  • @JosephSible-ReinstateMonica it is very complicated. I do not think there is any "right" answer. Because at the same time they are putting on a good show for one audience (people who know they should be concerned about Bobby Tables, but not sure what it is), they are putting on a bad show for another audience (people convinced that security theater is bad security). But if they removed the restriction, that would also be security theater. – emory Oct 25 '21 at 21:01
  • 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. – Joseph Sible-Reinstate Monica Oct 25 '21 at 21:06
  • @JosephSible-ReinstateMonica security theater - the practice of taking security measures that are intended to provide the feeling of improved security while doing little or nothing to achieve it. Increasing the character set by 3 would provide some users the feeling of improved security, but its actual security value would be negligible. Assuming there are 70 "good" characters and 3 "bad" characters, are you going to argue that there is enough entropy with all characters but not enough if you exclude the bad? – emory Oct 25 '21 at 21:15
  • Are you arguing that a security improvement shouldn't count just because it was basically good enough before? – Joseph Sible-Reinstate Monica Oct 25 '21 at 21:30
  • @JosephSible-ReinstateMonica if it was basically good enough before and the change was made primarily to provide the feeling of improved security, then it does count as security theater. – emory Oct 25 '21 at 22:02
  • 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. – user3067860 Oct 26 '21 at 15:33
  • 1
    @user3067860 I agree with you on that. I think there should be some standard body that says the universally approved password alphabet is A-Za-z0-9 (or whatever) and that all systems must accept passwords of length 32 characters (or whatever). Then password managers can conform to that and web applications that don't conform are self-identifiying shit birds. Once updated with the alphabet and length, my password manager can spit out valid passwords without me doing anything. – emory Oct 26 '21 at 16:57
  • @emory We came up with a solution for this (standardizing character sets for use in transit and handling) in the 90s, it's called "base64 encoding" and it solves every variation of this problem I've ever encountered, it's super inexpensive, maximally permissive, has 0 collision chance, and support for it comes packaged as a default globally available function in every web browser. People have insisted on persisting this non problem for almost 30 years. There is no helping them. – Iron Gremlin Oct 26 '21 at 23:01
1

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.

Jeff
  • 3,599
  • 4
  • 17
  • 23
  • 7
    What 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. – ilkkachu Oct 24 '21 at 19:51
  • 3
    Passwords 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. – Charles Duffy Oct 25 '21 at 00:40
  • 1
    I 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. – emory Oct 25 '21 at 21:22
0

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.

Nathan Goings
  • 858
  • 6
  • 14