[Cryptography] Spaces in web passwords

[Kevin W. Wall]

On Sat, Jun 21, 2014 at 3:13 PM, Chris Tonkinson <chris at masterbran.ch> wrote:
>> I'm baffled as to the threat model.  We're supposed to use symbols, aren't
>> we, so what's wrong with a blank?  Are their backends really that broken,
>> or are spaces susceptible to some obscure attack, or what?
>
>   The only "legitimate excuse" for this is a backend infrastructure
> which given such a limitation is - by definition - vulnerable to some
> form of injection. I'd love to see the following model gain popularity:

This whole "ignoring whitespace in passwords" goes back probably at
least a dozen years.

One such "backend infrastructure" is RSA Access Manager (fka, ClearTrust).
My team discovered this about 10 years ago when our director of Information
Security called up and said her password wasn't working with certain internal
web sites protected by Access Manager. Turned out that her AD / LDAP password
had a trailing space, but the Access Manager code was calling String.trim()
and thus deleting leading and trailing whitespace. We contacted RSA customer
support and they explained to us that this was a "feature" (and one
that couldn't be
disabled) added because some of their client customer organizations
had configured
Access Manager to store passwords as cleartext in their custom DB and
some of those
companies simply chose to have the "forgot password" use case email
the user back
their current password. As it was explained, apparently RSA had gotten so many
complaints about the passwords that were emailed back (via custom written code
mind you) that the passwords were not working. Turns out some of those
users were
simply doing a copy-and-paste from their MUAs into a web form and the 'copy'
did not select the unseen trailing whitespace in the email and since
it wasn't visible,
the users didn't know / remember it was there. (Who knows? It may have even
been why they forgot their password.)

So, yes, there are backend infrastructures that disallow this, and as of my last
involvement with RSA Access Manager 3 years or so ago, this was still something
that a company deploying RSA Access Manager couldn't change. :(

>   The "strength" of the attempted password is not directly based on
> length or character set, but rather actual probablistic complexity is
> calculated from same and a target complexity is set as the metric for
> acceptability, not directly "8 characters with an upper case and a symbol."
>
>   Assuming proper hashing on the server - another topic entirely - the
> passphrase: "airspeedvelocityofanunlaidenswallow" is provably orders of
> magnitude (approximately 34, to be exact) more resistant to brute force
> than "Monkey1!" yet the former would be rejected by many systems which
> would happily accept the later - probably with a complimentary green bar
> provided by some jQuery plugin.

While all that is likely true, the problem is that  those same organizations
that substantially reduce the character set also restrict the users to some
"reasonable" (their words) password length, so users' are screwed all
around. In fact it was such an experience that caused me to write my
"Signs of Broken Authentication" blog post series. I had found a situation where
a out-sourced vendor who was handling one of our benefits and also had
phone support (enter your SSN and password on telephone keypad). The
one and only time I used that service (no Internet access), I was thinking, "how
can I do this as my password has upper and lower case characters" [which
was required by their web-based "change password" form]. Then I decided
to try the usual alphabetic character to keypad # mapping and it worked. I
later tried the same all-numeric password from the web form and it worked
there as well! So I sent the company a nasty email (they never replied)
and promptly doubled the length of my password. I was especially pissed
because the "change password" web form never mentioned that they were
doing that.

Since that time, I have encountered this a few more times and have discovered
countless places where the alphabetic characters in passwords are treated
in a case insensitive manner.

So, that's the reality of the situation we are dealing with.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.