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.
Comment | File | Size | Author |
---|---|---|---|
#7 | 320162-logintoboggan-allow-spaces.patch | 1.3 KB | xurizaemon |
#4 | 320162-logintoboggan-optional-badchars.patch | 2.87 KB | xurizaemon |
Comments
Comment #1
hunmonk CreditAttribution: hunmonk commentedif 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.
Comment #2
dman CreditAttribution: dman commentedI'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/
... whenmypass
=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.
Comment #3
hunmonk CreditAttribution: hunmonk commentedi find dman's argument pretty convincing.
Comment #4
xurizaemonHi 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:
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?
Comment #5
dman CreditAttribution: dman commentedI 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.
Comment #6
hunmonk CreditAttribution: hunmonk commentedwe're looking at two issues here:
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.
Comment #7
xurizaemonWhat 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):
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:
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.
Comment #8
xurizaemonHoping 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).
Comment #9
xurizaemonI 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,
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.
Comment #10
dman CreditAttribution: dman commentedSounds 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.
Comment #11
hunmonk CreditAttribution: hunmonk commentedthe 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?
Comment #12
xurizaemonit 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
Comment #13
hunmonk CreditAttribution: hunmonk commentedtested and committed patch from #7 to 5.x, 6.x, and HEAD -- thanks for your work on this.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.