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

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

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.

@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.

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.

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.

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.

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.

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.

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.

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.

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?

@thibaudcolas
As of November 2020 a package called maskpass exists.
(It hasn't seen a release since November 2022 so maybe this is an issue or maybe it isn't.)

https://pypi.org/project/maskpass/
https://github.com/FuturisticGoo/maskpass

Certainly there are benefits for the standard library having this functionality though. 😉
Hope this helps.

omg! Yes please :)

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.

💯% agree with @Stevoisiak that if the asterisks masking feature is added it should be across all platforms.

Would it be unnecessary scope creep to allow the masking character to be user-defined?
(The default mask character wouldn't do anything unless the boolean is True.)
(Checking the mask character string length < 2 as well.)

getpass.getpass(show_mask=True, mask_character='*')

# or a Unicode bullet character
getpass.getpass(show_mask=True, mask_character='•')

# or even more creative with Unicode (ok, yes, getting silly here)
getpass.getpass(show_mask=True, mask_character='🐧')

The simplest road forward is likely to go with asterisks as a "static" mask character first.
If a configurable masking character is blessed/allowed then make that phase two of changes.

looks like a good idea, I'm ready to start working on it and I would also like to suggest an idea to replace:

getpass.getpass(show_mask=True, mask_character='*')

to:

getpass.getpass(mask='*')

with mask=None by default, and it will be displayed if bool(mask) == True (if mask: ...)

I also want to ask are you sure that we need a check for the length of mask, because some emoji may have a longer length or the user may want to use their own custom string. I don't insist, I just think this restriction is far-fetched.

to:

getpass.getpass(mask_character='*')

with mask_character=None by default, and it will be displayed if bool(mask_character) == True (if mask_character: ...)

I like the idea to default to None.

And yes - it can simply be:

if mask_character:
    # display mask character to stdout

I also want to ask are you sure that we need a check for the length of mask_character, because some emoji may have a longer length or the user may want to use their own custom string. I don't insist, I just think this restriction is far-fetched.

@donBarbos I wasn't thinking about multi-character emojis. 😉

Either way, since you bring it up, it seems reasonable to allow for flexibility. 👍

Looks like a PR was merged for this, so this could be closed.

However, there's an issue: the PR added the new parameter only to unix_getpass and win_getpass but not to fallback_getpass. Let's add it there too for consistency.

Right, it's also needed at runtime as getpass is set to fallback_getpass in case msvcrt fails to be imported.

sorry, I can send PR soon.
note: I left a comment about this #130496 (comment)