Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

open
Darryl Dixon
None
5
2005-07-07
2005-06-21
Adrian Sanabria
No

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.

Discussion

  • Darryl Dixon
    Darryl Dixon
    2005-06-21

    • assigned_to: nobody --> esrever_otua
     
  • Darryl Dixon
    Darryl Dixon
    2005-06-21

    Logged In: YES
    user_id=567623

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

    Cheers,
    D

     
  • Darryl Dixon
    Darryl Dixon
    2005-06-29

    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
    Darryl Dixon
    2005-06-29

    • status: open --> pending
     
  • Darryl Dixon
    Darryl Dixon
    2005-06-29

    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
    Darryl Dixon
    2005-07-06

    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

     
    • status: pending --> open
     
  • 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?