We have had complaints from security conscious users that LoginToboggan prevents users changing passwords to use spaces.

Using non-alphanumeric characters is encouraged for increased security, and I'm not aware of any issues that would arise from spaces being used.

Can someone explain why LoginToboggan does this? I'd just comment out the relevant line, but I want to check first if LoginToboggan has a specific need for there to be no spaces in passwords. I suspect it was just a feature request that's been added without being made configurable.

Happy to supply a patch to make this site-configurable, if that's what it takes.

Comments

Status:Active» Postponed (maintainer needs more info)

if you would be able to point me to some official or semi-official documentation about password security, that would be helpful for making any changes to the password validate function.

I'd say it's convention, and not one worth breaking.

Spaces are disallowed in unix accounts AFAIK, if not they would cause much trouble for SSH, FTP, daemon and MySQL scripts that didn't forsee anyone wanting to do that.
It's allowed to be entered in htauth passwords, however support to actually use it may vary depending on the protocol. I lost a few hours debugging a password that included an '@' symbol in it once. Turns out the htauth was interpreting it as a special symbol behind the scenes, http://myname:mypass@the.server/ ... when mypass = myp@ss ... you see that happening? What would spaces do?
MS user manager DOES allow spaces, but advises not to begin or end with them. There have been reports of LDAP failing in some cases with spaces.

Anyway ... None of this applies directly to why Drupal authentication must not use spaces if it damn well wants to. It's making its own sytems. But the question is : why break with convention when it may cause untested problems at some point further down the track? I would not want to teach a user that spaces were OK, Then next month have to give them an FTP account or email account where it wasn't, or caused silly, hard-to-find errors.

The case against it - "It's a silly idea with hard-to-debug pitfalls" is stronger than the case for it.
What is the case for it? Security conscious? Entering one more character into the mix is not going to make it any cryptographically stronger.

.dan.

Status:Postponed (maintainer needs more info)» Closed (won't fix)

i find dman's argument pretty convincing.

Status:Closed (won't fix)» Needs review
StatusFileSize
new2.87 KB

Hi Dan -

It's not my experience that UNIX forbids spaces in passwords; I just tested this, and it was quite happy to allow me a space in a password (tested on both Debian Etch and OSX).

If the argument is "allowing spaces breaks tradition/convention", I think the relevant "convention" here is how Drupal does things. Drupal permits spaces in passwords.

Our case for not changing Drupal's default behaviour in this regard:

Passphrase logins are a common use case of spaces in passwords. By rejecting a particular character in passwords, we cause confusion for our users.

I'm unconvinced that allowing spaces in passwords is necessarily a silly idea, particularly as it's the default behaviour of Drupal. We've had a couple of reports from users that they don't like it, anyway.

Attached is a patch which allows people to turn off the bad character check in LoginToboggan. This seemed a more reasonable patch to offer than one which simply removes the functionality we're having issues with, but I'm happy to supply the alternative if you prefer.

I hope that making this a configurable option is an acceptable solution for you?

I won't object to allowing it - I was just brainstorming some of the potential implications. I have no strong feelings.

Seeing as drupal core does allow it, it does certainly make sense for logintoboggin to follow, doing otherwise is inconsistant. I didn't pay attention to this being just a logintobbogin issue and was thinking about password policy in general.

Status:Needs review» Needs work

we're looking at two issues here:

  1. how to validate a password in a standard/conventional way
  2. whether or not to include an option for disabling said password validation

we shouldn't be lumping these together, so for this issue, let's focus on #1.

i had no hand in writing that password validation code, and i have minimal understanding of password conventions. therefore, i'm inclined not to touch that code _until_ i see some hard evidence that it needs to change (ie, some official/semi-official documentation of a standard, from an organization such as IETF). since i have no issue with the current validation, i have no impetus to search out anything like that. but, if someone is willing to do that and provide a patch which makes the password validation more standards compliant, then i will be happy to review it, and commit if it's a solid patch.

i won't consider an option to disable validation in this issue.

Title:LoginToboggan prevents use of spaces in passwords, breaking passphrase functionality"The password cannot contain spaces" - Why?
Category:bug» support
Status:Needs review» Needs work
StatusFileSize
new1.3 KB

What I consider to be the "standard" is Drupal's default behaviour. Obviously LoginToboggan exists specifically to modify Drupal's behaviour from the default, but I'd like to be able to use the great features LoginToboggan offers without it restricting Drupal's functionality in other regards.

To focus on the original issue (allowing the space character in passwords, so as to allow users to use passphrases):

  • Drupal 5.x, 6.x and 7.x allow spaces in passwords
  • LoginToboggan currently gives an error if a user attempts to use a space in a password
  • The result is that we have complaints from users who use passphrases, stating that our password validation routines are inconsistent with other websites
  • The rationale for LoginToboggan preventing the use of spaces is not obvious and dates back to an early release

Chad, here are some references which encourage the use of special characters/punctuation in passwords. Some refer specifically to spaces while others just advise generally to use extended characters. My understanding of password conventions is minimal also, but I believe from my research so far that allowing spaces is the conventional approach.

I've done an informal survey of high-use websites (eg Gmail, Yahoo, Facebook, etc etc) and couldn't find a single one which prevented using spaces in passwords.

I wonder if the "no spaces in passwords" was related to an earlier release of Drupal emailing users passwords, and resulting confusion when users copied passwords from emails. Googling for "drupal password spaces" seems to indicate this was once an issue, but would now be resolved by the one-time login links current Drupal releases generate.

An earlier patch was accepted which removed the restriction on some useful characters ($^%!) but did not remove the restriction on the space character.

Please consider my suggested solutions, which are to do one of the following:

  • Apply the patch attached to this comment, which removes only the "password cannot contain spaces" check, in accordance with Chad's suggestion
  • (less preferable to us) Apply the patch in comment #4, which allows site admins to disable LoginToboggan's password validation functionality on a per-site basis, freeing them to supply their own password validation functionality

The first patch I supplied allows site-configurable disabling of LoginToboggan's validation routine, but our only real issue is with blocking the use of space, which is a valid character for passwords in most systems/protocols (including MySQL, FTP, HTTP, SSH, and UNIX login accounts). The second patch (this comment) is the one I prefer; it only fixes the issue we have, and allows the use of spaces.

If those options aren't acceptable, I'd really appreciate it if someone can please document the benefits of having LoginToboggan alter Drupal 5/6/7's default behaviour of accepting passwords containing a space.

Title:"The password cannot contain spaces" - Why?LoginToboggan prevents use of spaces in passwords, breaking passphrase functionality
Category:support» bug
Status:Needs work» Needs review

since i have no issue with the current validation, i have no impetus to search out anything like that. but, if someone is willing to do that and provide a patch which makes the password validation more standards compliant, then i will be happy to review it, and commit if it's a solid patch.

Hoping the supplied references and patch in previous comment meets your standards. if not, please let me know how I can improve this?

I should have updated the issue status when posting the last message; also changing category from "support request" (my initial enquiry as to why spaces are banned) to "bug report" as per the updated title (Drupal supports passphrases using spaces; LoginToboggan does not).

Title:"The password cannot contain spaces" - Why?LoginToboggan prevents use of spaces in passwords, breaking passphrase functionality
Category:support» bug
Status:Needs work» Needs review

I contacted Gary to ask why the space removal code was included, as it appears that the earliest version of LoginToboggan with this code was checked in by him.

Gary replied,

I don't really know why spaces would have been prohibited. I would expect that any password system would always strip
spaces from the beginning and end of a password, purely for usability. But that shouldn't prevent spaces in the middle.

Are you happy with the patch in comment 7?

Is there anything else I can do to help see this issue resolved?

Update: the "no spaces allowed" code was actually checked in by jjeff - not Gary. The "no spaces" code dates to a time when Drupal sent passwords out by email, and this was a cause of confusion for users, but that's no longer an issue.

Sounds like a comprehensive investigation into that :)
I'm convinced. Thanks for your commitment.
... however I have no connection with logintoboggin - I was just sticking my 2c in.

the patch in #7 adds a space to this line of code:

if (ereg("[^\x80-\xF7[:graph:]]", $pass)) return t('The password contains an illegal character.');

why?

it adds a space to the list of allowed characters - otherwise that patch would not fix the bug, and logintoboggan would continue to complain about spaces in passwords

you can use ereg("[^\x80-\xF7[:print:]]", $pass) instead of ereg("[^\x80-\xF7[:graph:] ]", $pass) if you prefer, should achieve the same thing

either is good by me

cheers

Status:Needs review» Fixed

tested and committed patch from #7 to 5.x, 6.x, and HEAD -- thanks for your work on this.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.