Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have a web application that takes a username/password and then authenticates against a Microsoft Active Directory. For the most part this works fine, unless the user has a special character in their password.

for example:

Passw0rd works just fine
Pa$sw0rd does not work.
P@ssw0rd does not work.
Password# does not work.


It seems to be when a symbol is used that perl uses in its syntax. I've tried escaping these characters by searching the string for them and placing a "\" before them, but this does not work.

Is there a solution to this problem, or should I provide a list of special characters that people should avoid in their passwords?

Replies are listed 'Best First'.
Re: Special Characters in Passwords
by holli (Abbot) on May 17, 2005 at 14:07 UTC
    Hard to tell without code. Wild guess: In your code you do some eval()ed operation with the password.


    holli, /regexed monk/
[reply]
[d/l]

      Authen::Smb is written in C. It could be a problem with CGI, but that would be most unexpected (and easily verifiable by printing $password).

[reply]
Re: Special Characters in Passwords
by Anonymous Monk on May 17, 2005 at 14:11 UTC
    Here's some code, and no, i do NOT use eval. 
    #!/usr/bin/perl -w
use strict;
use CGI;
my $query    = CGI::new();
my $username = $query->param('username');
my $password = $query->param('password');
my $authResult = Authen::Smb::authen($username,
                                     $password,
                                     'pdc',
                         'bdc',
                                     'domain');
return(1) if !$authResult;
return(0);

    [download]
[reply]
[d/l]

      Since you are getting your username and password from a CGI query, I suggest you use Data::Dumper to find out what is really being given to your script. Perhaps some encoding is being done that CGI is not catching.

      You're probably aware that browsers frequently encode form fields before passing them to GET; some browsers do this (usually to a lesser extent) for POST requests, too. CGI modules typically un-encode them, but maybe something is being missed here?

      Incidentally, I highly recommend CGI::Simple as a replacement for CGI: it drops in to most CGI-using scripts without any serious code modification, and it has worked much better for me in every case.

      The Eightfold Path: 'use warnings;', 'use strict;', 'use diagnostics;', perltidy, CGI or CGI::Simple, try the CPAN first, big modules and small scripts, test first.

[reply]
      That can't be the code you used to get the results you described. Authen::Smb is not even used! Don't post code you think is equivalent. Verify first.
[reply]
[d/l]

      You may not be using eval, but it's possible that Authen::Smb::authen() is doing something odd with the values.

      It's also possible that the system has set up policies that restrict the use of specific characters. (most directory systems do, so that you can set more restrictive character sets, because some of the systems that authenticate off of them may have problems with characters ... for instance, '#' and '+++' could get you into problems depending on how you're connecting to the system)

      I've never used Authen::Smb, so I don't know if there's a way to tell from the error messages generated (if there are any -- you just said the infamous 'didn't work') if you can tell what type of error it actually was (something caused at the client side, or the server side) ... eg, does $authResult have any extra info in it?

[reply]
[d/l]

Back to Seekers of Perl Wisdom