#8 Extended ASCII/ANSI characters in NTLM passwords do not work

[Adrian Sanabria]

A password containing an extended ASCII character
cannot be entered, either in server.cfg, or by hand
into the console window. My purpose for doing this is
to make my passwords more difficult to brute force by
expanding the number of possibilities one would have to
include in a brute force password attack.

What I am calling an "extended ASCII character" would
be any character that isn't A-Z, a-z, 1-9 or any
standard punctuation (any character above ANSI 126).

I tried to accomplish this by making passwords in other
languages, where passwords would still be easy to
remember, but I could use accented letters that are
part of the extended set, such as:

ń, á, é, í, ó, ú

and some punctuation as well, like the inverted
exclamation point ( Ą ), and the inverted question mark
( ż ).

This problem can be reproduced in versions 0.9.7 -
0.9.9, and probably in the 0.9.9.5 development version
as well.

[Darryl Dixon]

Logged In: YES
user_id=567623

Thanks Adrian, will look into how best to support these.

Cheers,
D

[Darryl Dixon]

Logged In: YES
user_id=567623

OK, I've taken a bit of a look, and here's the current state
of play:

Normal MS LM hashes don't support anything but ASCII codes
0-127 (or, more precisely, anything above that they map back
to codes in the 0-127 range by way of a lookup table.). The
default config for ntlmaps, is to just use LM only. This
will be the default for the foreseeable future as it offers
the best, most widely tested compatability. Thus, extended
ASCII won't work in a default ntlmaps setup (we don't have a
lookup table, and it defeats the purpose when using LM anyway).

However, ntlmaps *does* support generating NT hashes, which
do work with extended ASCII codepages. So far so good. If
the password is stored in the config file, this all works.
However, when inputting the password directly at the command
prompt, ntlmaps uses the Python getpass.getpass() method.
This method *does not support* capturing extended ASCII
chars by way of the ALT key (eg, ALT+115 does not generate
's', it generates an empty string), and it also does not
support extended characters input by way of COPY+PASTE from
a Character Map. Whilst documentation for getpass is a bit
thin on the ground, it seems that it just doesn't support
these characters, full stop.

This is therefore a Python limitation that has bitten us.

I am going to have a think about this, and probably a read
of the getpass sourcecode. It may be that a custom
data-input routine may need to be written to support
extended characters being input at runtime.

Watch this space.

D

[Darryl Dixon]

Logged In: YES
user_id=567623

I've done some more research on the getpass() issue. On
*nix it works OK (with COPY+PASTE), but on Windows there are
some problems in the base Python C code that gets the input.
I have sent an email to python-dev to query adding support
(see:
https://sourceforge.net/mailarchive/forum.php?thread_id=7614973&forum_id=43057\),
but this isn't likely to help existing users of existing
Python releases (assuming they do implement support).
Especially this will not be of use to people still using
Python 1.5.2, which is (still) our tier-1 supported platform
(heh :).

I'll see what comes of the email to python-dev, and then
investigate if there are any other alternatives for users of
existing Python releases.

Cheers,
D

[Darryl Dixon]

Logged In: YES
user_id=567623

OK, here's where we're at:

After a resounding dearth of assistance from python-dev
(Hear that sound? That's the sound of _nobody_ on
python-dev offering any constructive assistance or
acknowledgement that getpass is lacking on win32 _at all_),
I have gone ahead and written up my own prototype extension
module in C with MinGW and SWIG that plays with the console
flags and the ReadConsole kernel32.dll function to get a
function that will accept input (including ALT+xxxx chars)
without echoing them back to the screen.

The problem now becomes 'how to support this on all possible
versions of Python in use'. The answer I'm toying with at
the moment is to distribute a version of the module for
Python 1.5.2 always, and a version for whatever the latest
stable Python version is at time of release (in other words,
that would be Python 2.4.1 currently). It will get
distributed along with source code, instructions, and build
files (a la GPL), so anyone that is so inclined can build it
for their installed version of Python and the world will be
good. For those that don't have a compatible Python
version, and who won't/can't build it for their own version,
I will implement a fallback to the usual getpass() call, and
maybe print a warning or something that extended chars
aren't supported.

I would like some input on your opinion here, and whether
this will meet your needs.

Cheers,
D

[Adrian Sanabria]

Logged In: YES
user_id=599980

That will meet my needs. So I just need to make sure this
module is loaded at runtime, and it will replace the default
Python getpass function? Does it require any code changes to
this project?