Adding the ability for getpass to print asterisks when password is typed

[c46a4f13-986a-406e-a0ff-a46d1640a576]

BPO	32884
Nosy	@stevendaprano, @bitdancer, @jab, @MatanyaStroh, @stevoisiak, @remilapeyre, @websurfer5, @akulakov

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'library', '3.9'] title = 'Adding the ability for getpass to print asterisks when password is typed' updated_at = user = 'https://github.com/MatanyaStroh' ``` bugs.python.org fields: ```python activity = actor = 'andrei.avk' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'matanya.stroh' dependencies = [] files = [] hgrepos = [] issue_num = 32884 keywords = [] message_count = 7.0 messages = ['312410', '312520', '312745', '339803', '344784', '375038', '399298'] nosy_count = 9.0 nosy_names = ['steven.daprano', 'r.david.murray', 'jab', 'matanya.stroh', 'stevoisiak', 'remi.lapeyre', 'Jeffrey.Kintscher', 'celal.sahin', 'andrei.avk'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue32884' versions = ['Python 3.9'] ```

[c46a4f13-986a-406e-a0ff-a46d1640a576]

I saw some questions about it in stackoverflow (links below), and also find it very useful to have the ability to print asterisks. Some users, find it disturbing when they don't have any indication that password is typed, and it will be helpful to have it.

I know that it's have some risks exposing the number of chars to the password, but I think it's worth it.

When using Jupyter (notebook server is 4.3.1) the password does echoed as "*", but not in Python IDE in linux and Windows

1) https://stackoverflow.com/questions/10990998/how-to-have-password-echoed-as-asterisks 2) https://stackoverflow.com/questions/7838564/how-to-read-password-with-echo-in-python-console-program

[c46a4f13-986a-406e-a0ff-a46d1640a576]

for getpass.win_getpass() it can simply be done by adding this line msvcrt.putch("*"). So the code will look like:

def win_getpass(prompt='Password: ', stream=None):
    """Prompt for password with echo off, using Windows getch()."""
    if sys.stdin is not sys.__stdin__:
        return fallback_getpass(prompt, stream)

    for c in prompt:
        msvcrt.putwch(c)
    pw = ""
    while 1:
        c = msvcrt.getwch()
        if c == '\r' or c == '\n':
            break
        if c == '\003':
            raise KeyboardInterrupt
        if c == '\b':
            pw = pw[:-1]
        else:
            pw = pw + c
            msvcrt.putch("*") #Line that was added
    msvcrt.putwch('\r')
    msvcrt.putwch('\n')
    return pw

[bitdancer]

getpass is emulating the unix password prompt behavior. I'm not sure if the complication is worth it, especially since not echoing asterisks is, as you observe, fractionally more secure. So I guess I'm about -.5 on this feature.

[0ccc5d38-a96a-4f59-85da-51e546869847]

@matanya.stroh: Don't forget to erase the asterisks if the user hits backspace.

def win_getpass(prompt='Password: ', stream=None, show_asterisks=False):
    """Prompt for password with echo off, using Windows getch()."""
    if sys.stdin is not sys.__stdin__:
        return fallback_getpass(prompt, stream)

    for c in prompt:
        msvcrt.putwch(c)
    pw = ""
    while 1:
        c = msvcrt.getwch()
        if c == '\r' or c == '\n':
            break
        if c == '\003':
            raise KeyboardInterrupt
        if c == '\b':
            if len(pw) > 0:
                pw = pw[:-1]
                msvcrt.putwch('\b')
                msvcrt.putwch(' ')
                msvcrt.putwch('\b')
        else:
            pw = pw + c
            if show_asterisks:
                msvcrt.putwch('*')
    msvcrt.putwch('\r')
    msvcrt.putwch('\n')
    return pw

Alternatively, could let the user define the masking character, similar to Tkinter's Entry widget.

def win_getpass(prompt='Password: ', stream=None, mask=''):
    """Prompt for password with echo off, using Windows getch()."""
    if sys.stdin is not sys.__stdin__:
        return fallback_getpass(prompt, stream)
    if len(mask) > 1:
        raise TypeError('mask argument must be a zero- or one-character str')

    for c in prompt:
        msvcrt.putwch(c)
    pw = ""
    while 1:
        c = msvcrt.getwch()
        if c == '\r' or c == '\n':
            break
        if c == '\003':
            raise KeyboardInterrupt
        if c == '\b':
            if len(pw) > 0:
                pw = pw[:-1]
                msvcrt.putwch('\b')
                msvcrt.putwch(' ')
                msvcrt.putwch('\b')
        else:
            pw = pw + c
            if mask:
                msvcrt.putwch(mask)
    msvcrt.putwch('\r')
    msvcrt.putwch('\n')
    return pw

I'm in favor of supporting masking. While it does reveal the password length, it's an accessibility feature many users have come to expect.

I'd rather have this in the standard library than have developers implement their own custom, potentially insecure methods for password input.

[stevendaprano]

See also bpo-36566. (Thanks Cheryl.)

I think the usability improvement for this far outweigh the decrease in security.

The days where somebody looking over your shoulder watching you type your password was the major threat are long gone. Hiding the length of the password against a shoulder-surfing adversary is so-1970s :-)

For old-school Unix types we ought to default to hiding the password. But I'm +1 in allowing developers to choose to trade off a tiny decrease in security against a major increase in usability.

The bottom line is that if you have a weak password, hiding the length won't save you; if you have a strong password, hiding the length doesn't add any appreciable difficulty to the attacker.

[4665e53e-3801-4da6-a20f-262e4f22a1df]

This is easy to implement for Windows (as shown), but the unix implementation uses io.TextIOWrapper.readline() to get the password input. The unix implementation would have to be rewritten to provide the same functionality.

[akulakov]

Unfortunately modern laptop keyboards have almost no key travel and barely any tactile feedback [*]. Users on such keyboards really do need feedback for each key pressed. Not providing an option for such feedback is in effect forcing users to choose maximally weak password.

[*] worse, a large proportion of MBP keyboards produced in the last few years have the notoriously bad 'butterfly' key design that occasionally duplicates and swallows keypresses. Yes, a trillion dollar company can't make a functional keyboard.

[thibaudcolas]

I’m surprised to see this opened for so long! Is this waiting on a design decision or pull request? Looking at the contribution guidelines for standard library changes, it seems the recommended course of action would be to create a new thread in Discourse under Ideas?

My two cents on the issue – it’s one of those we run into at every single workshop / training for newcomers to open source like Django Girls. There‘s no feedback when typing. In the case of Django, there’s no indication not to expect any feedback either. Lots of people use Windows and will have never come across that kind of prompt ever. So as mentioned above – this is indeed encouraging people to choose a password that’s simple to type.

[Stevoisiak]

I’m surprised to see this opened for so long! Is this waiting on a design decision or pull request? Looking at the contribution guidelines for standard library changes, it seems the recommended course of action would be to create a new thread in Discourse under Ideas?

I don't see much opposition to this change, but somebody would need to write an implementation that works on Unix.

[thibaudcolas]

Thanks for looking into this @Stevoisiak. Would it be acceptable to fix this for Windows users to start with, and change it for Unix users later?

From my perspective I see this has been opened for close to 6 years now even though people seem to think it’s a simple change for Windows. As a regular Django Girls coach this has basically been an issue for Windows users at every event I’ve ever coached at, where we run into this when creating a user account’s password for Django.

[Stevoisiak]

Thanks for looking into this @Stevoisiak. Would it be acceptable to fix this for Windows users to start with, and change it for Unix users later?

From my perspective I see this has been opened for close to 6 years now even though people seem to think it’s a simple change for Windows. As a regular Django Girls coach this has basically been an issue for Windows users at every event I’ve ever coached at, where we run into this when creating a user account’s password for Django.

I've also wanted to see this feature for a while. (I proposed a Windows implementation in 2019, which itself may have been based on a post from 2013), but implementing it only on Windows would likely lead to confusion. If this were officially implemented and a Python script calls getpass.getpass(show_asterisks=True), most reasonable users would expect their script to show asterisks regardless of whether it's running on Windows, Linux/Unix, Mac, or any other officially supported platform.

[thibaudcolas]

Isn’t it the current implementation that defies people’s expectations? The current win_getpass function implements the behavior of getpass from Unix (to log in?), which never shows passwords, so is "as-expected" for Unix users of Python. But on Windows – password prompts definitely show asterisks, hence why it’s confusing the ones implemented with Python don’t?