Password masking for getpass.getpass
Greetings, I am working on a project and I am using getpass.getpass() to grab passwords from the user. Some of the users wanted asterisks to be displayed when they were typing in the passwords for feedback i.e. how many characters were typed and how many to backspace. Therefore I have created a solution but I think the feature should come by default (and the programmer should have the option to use a blank or any other character). The code lives here: https://goo.gl/OeY3QI Please let me know about your thoughts on the issue. Also my apologies if this is the wrong mailing list. Please guide me in the right direction if that is the case. Sincerely, King Mak
On Wed, Jan 13, 2016 at 12:11 PM, Muhammad Ahmed Khalid <khali119@umn.edu> wrote:
First off, here's a direct link, bypassing the URL shortener. https://code.activestate.com/recipes/579148-add-password-masking-ability-to-... The use of raw_input at the end suggests that you're planning this for Python 2.7, and not for 3.x. Does your code work (apart from that, which is insignificant) on Python 3? If not, this would be well worth considering; this mailing list is all about new features for the new versions of Python, which means 3.6 at the moment. Cool snippets of Py2 code might be useful as ActiveState recipes, or as PyPI modules, but they won't be added to the core language. You've used the Windows-only msvcrt module. That means your snippet works only on Windows, which you acknowledge in a comment underneath it. I'm echoing that here on the list to make sure that's clear. Have you checked PyPI (pypi.python.org) for similar code that already exists? ChrisA
On Tue, Jan 12, 2016 at 07:11:55PM -0600, Muhammad Ahmed Khalid wrote:
I think that's an excellent idea. The old convention on Linux and Unix is to just suppress all feedback, but even on Linux GUI applications normally show bullets • or asterisks. Users who are less familiar with old-school Unix conventions have trouble with the standard password idiom of suppressing all feedback.
I think that the default should remain as it is now, but I would support adding an extra argument for getpass() to set the feedback character. But it would need to support POSIX systems (Unix, Linux and Mac OS X) as well as Windows. -- Steve
Hi! On Wed, Jan 13, 2016 at 12:54:14PM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
The old convention on Linux and Unix is to just suppress all feedback, but even on Linux GUI applications normally show bullets ??? or asterisks.
Modern GUIs show the real character for a short period of time and then replace it with an asterisk. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Wed, Jan 13, 2016 at 1:17 PM, Oleg Broytman <phd@phdru.name> wrote:
Ugh. I've only seen that on mobile devices, not on any desktop GUI, and I think it's a sop to the terrible keyboards they have. I hope this NEVER becomes a standard on full-sized computers with real keyboards. ChrisA
On Wed, Jan 13, 2016 at 01:22:02PM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On desktop (Windows) I saw a password entry with a checkbox to switch between real characters and asterisks.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
I've gotten some ideas from people's emails and I think it is worth investing more time with this feature. I will work to make the code platform independent and python 3 compatible. The standard library code for getpass.getpass() actually does use msvcrt for the windows platform so I think I'll keep my code like that but I'll add another function supporting unix. Considering the mobile device issue: there can always be options. The developers can choose either to implement that feature or not and even more let the users decide if they want to use the feature. This is exactly what i am aiming for with the desktop version too. The ability to choose. ~ KingMak On Tue, Jan 12, 2016 at 9:07 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 13.01.2016 04:07, Ethan Furman wrote:
At least in Windows GUIs, the password field only provides a very thin layer to obfuscate the underlying password text: http://www.nirsoft.net/utils/bullets_password_view.html More secure systems always show 8 bullets regardless of how many characters the password actually has and only provide limited feedback when hitting a key without allowing to see the number of chars in the password. Not showing anything is certainly more secure than any other method of providing user feedback, so I agree that we should not make this the default. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 13 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
FYI: prompt_toolkit can prompt for password input: https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/exampl... https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/exampl... It displays as asterisks and keeps all readline-like navigation. The second is an example of password input where Ctrl-T toggels between asterisks and all visible. Feedback is welcome (create an issue), but this probably will never become part of core Python. Jonathan 2016-01-13 11:36 GMT+01:00 M.-A. Lemburg <mal@egenix.com>:
On Wed, Jan 13, 2016 at 01:22:02PM +1100, Chris Angelico wrote:
I don't know... I'm about 35% convinced that obfuscating the password is just security theatre. I'm not sure that "shoulder surfing" of passwords is a significant threat. But the other 65% tells me that we should continue to obfuscate. -- Steve
On Wed, Jan 13, 2016 at 9:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
In some situations it's absolutely appropriate to not hide the password at all. (A lot of routers let me type in a wifi password unobscured, for instance.) But if you're doing that, then just keep the whole password visible, same as if you're asking for a user name. Don't show the one last-typed character and then hide it. You're quite probably right that obfuscating the display is security theatre; but it's the security theatre that people are expecting. If you're about to enter your credit card details into a web form, does it really matter whether or not the form itself was downloaded over an encrypted link? But people are used to "look for the padlock", which means that NOT having the padlock will bother people. If you ask for a password and it gets displayed, people will wonder if they're entering it in the right place. That said, though, I honestly don't think there's much value in seeing the length of a password by the number of asterisks. Have you ever looked at them and realized that you missed out a letter? But again, they're what people expect... ChrisA
On 13 January 2016 at 10:19, Chris Angelico <rosuav@gmail.com> wrote:
Personally, I frequently look at the line of asterisks and think "that doesn't look right" - it helps me catch typos. Also, doing things like deleting everything but the first N characters lets me retype from a "known good" point. I tend to get uncomfortable when I get no feedback at all, as is typical on Unix systems. But yes, it's about expectations, and it depends what type of system you typically work with. Although many, many people are used to seeing feedback asterisks or similar, as that's the norm on Windows and in many (most?) web applications. Paul
As in everything, it depends on the situation: https://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html The Security Now podcast has also expressed doubt on the practice in common cases. My take is that a few flags to control the behavior with convenient defaults perhaps, show_text=True, display_char=None, display_delay=0, and a Ctrl-T keybinding to toggle (as mentioned elsewhere). A good case could also be made for the most secure defaults instead. As long as the toggle keybinding were available it wouldn't be a great burden. This is a console-only solution, correct? So, Ctrl/Alt keys should be available. -Mike On 2016-01-13 02:04, Steven D'Aprano wrote:
On 01/13/2016 11:04 AM, Steven D'Aprano wrote:
This might not apply for people working from home, but at work I regularly enter my own password or passwords for other systems with other people intentionally looking over my shoulder (e.g. pair-programming, debugging, confirming error reports etc.) Should I ask them to look away from the screen each time? cheers, Georg
Regarding the issue of people looking at the user typing in the password. Unless the person looking is right next to the user, it doesn't really matter if they look at the screen, because if password masking is enabled they will only see the masking characters. If the person looking is right next to the user then that person can just look at the keyboard and the keys being pressed. Also the main issue here is that there should be a choice provided by the getpass function to provide feedback or not. On Thu, Jan 14, 2016 at 3:50 AM, Georg Brandl <g.brandl@gmx.net> wrote:
On 01/14/2016 11:07 AM, Muhammad Ahmed Khalid wrote:
Well, I can type reasonably fast. For Chris and anyone else who'd like to pretend not to know what I meant: The point is that these are *coworkers*, not *hackers*. They have no reason to go to great lengths to know these passwords. But at the same time, they're not theirs to know, and I'd like to keep them to myself, otherwise we could just use one company-wide password for everything. Having the password masked on the screen, where eyes will be anyway, is a good compromise to avoid needless interruptions. Georg
This discussion is kind of going into different directions and I want to bring it back to the getpass function. The original argument is that there should be a choice provided by the getpass function of getting feedback or not. Currently the getpass function does not provide any feedback and I just want to add the ability to make it so that I can get some feedback. Some one earlier mentioned that by default the function will not echo anything back and I totally agree with that. In fact I like that suggestion a lot. Only when the users* want feedback they can change the parameters of the function and add which ever character they want for masking. Please note that currently the first parameter of the getpass function is the Prompt. The second parameter can then be used as the masking character which can be None / blank by default. On Thu, Jan 14, 2016 at 4:08 AM, Chris Angelico <rosuav@gmail.com> wrote:
On 14.01.2016 11:29, Muhammad Ahmed Khalid wrote:
If you can make this work cross-platform, I don't think anyone would object to having such an option, as long as the default remains "show nothing" :-) For more complex password / key card / single signon / etc. functionality, I believe a PyPI installable package would be better. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 14 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
Georg Brandl wrote:
I have a solution! It requires a display capable of emitting light with selected polarisation. The password field displays the password in such a way that it can only be seen when wearing polariod glasses that are polarised in the correct direction. So a pair of programmers can wear glasses that let them each see their own password but not the other's. Bystanders not wearing any glasses would not see either of them. -- Greg
On 1/12/2016 8:11 PM, Muhammad Ahmed Khalid wrote:
You are debating the wrong issue. I work at home. I HATE Passwork Masking Security Theatre. Since I cannot reliably type 10 random hidden characters (or so sites tell me), it causes me endless grief for 0.00000% gain. If any of my passwords is stolen, it will, with probability 1.0 - epsilon, be part of one of the hacks that steal millions at a time from corporate sites. Epsilon would be something other than a stranger looking over my shoulder. http://www.zdnet.com/article/we-need-to-stop-masking-passwords/ PS: When UNIX decided to give no feedback, most people had one short easy-to-remember, easy-to-type password. Not a hundred hard to remember and type. --- Terry Jan Reedy
Sounds like this default should be user configurable as well, not only by the developer. Perhaps a function call to set the preference in PYSTARTUP? (or other precedent). A hotkey to toggle would be helpful for laptops, which tend to travel. -Mike On 2016-01-13 16:29, Terry Reedy wrote:
I HATE Passwork Masking Security Theatre.
On Wed, Jan 13, 2016 at 12:11 PM, Muhammad Ahmed Khalid <khali119@umn.edu> wrote:
First off, here's a direct link, bypassing the URL shortener. https://code.activestate.com/recipes/579148-add-password-masking-ability-to-... The use of raw_input at the end suggests that you're planning this for Python 2.7, and not for 3.x. Does your code work (apart from that, which is insignificant) on Python 3? If not, this would be well worth considering; this mailing list is all about new features for the new versions of Python, which means 3.6 at the moment. Cool snippets of Py2 code might be useful as ActiveState recipes, or as PyPI modules, but they won't be added to the core language. You've used the Windows-only msvcrt module. That means your snippet works only on Windows, which you acknowledge in a comment underneath it. I'm echoing that here on the list to make sure that's clear. Have you checked PyPI (pypi.python.org) for similar code that already exists? ChrisA
On Tue, Jan 12, 2016 at 07:11:55PM -0600, Muhammad Ahmed Khalid wrote:
I think that's an excellent idea. The old convention on Linux and Unix is to just suppress all feedback, but even on Linux GUI applications normally show bullets • or asterisks. Users who are less familiar with old-school Unix conventions have trouble with the standard password idiom of suppressing all feedback.
I think that the default should remain as it is now, but I would support adding an extra argument for getpass() to set the feedback character. But it would need to support POSIX systems (Unix, Linux and Mac OS X) as well as Windows. -- Steve
Hi! On Wed, Jan 13, 2016 at 12:54:14PM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
The old convention on Linux and Unix is to just suppress all feedback, but even on Linux GUI applications normally show bullets ??? or asterisks.
Modern GUIs show the real character for a short period of time and then replace it with an asterisk. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Wed, Jan 13, 2016 at 1:17 PM, Oleg Broytman <phd@phdru.name> wrote:
Ugh. I've only seen that on mobile devices, not on any desktop GUI, and I think it's a sop to the terrible keyboards they have. I hope this NEVER becomes a standard on full-sized computers with real keyboards. ChrisA
On Wed, Jan 13, 2016 at 01:22:02PM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On desktop (Windows) I saw a password entry with a checkbox to switch between real characters and asterisks.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
I've gotten some ideas from people's emails and I think it is worth investing more time with this feature. I will work to make the code platform independent and python 3 compatible. The standard library code for getpass.getpass() actually does use msvcrt for the windows platform so I think I'll keep my code like that but I'll add another function supporting unix. Considering the mobile device issue: there can always be options. The developers can choose either to implement that feature or not and even more let the users decide if they want to use the feature. This is exactly what i am aiming for with the desktop version too. The ability to choose. ~ KingMak On Tue, Jan 12, 2016 at 9:07 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 13.01.2016 04:07, Ethan Furman wrote:
At least in Windows GUIs, the password field only provides a very thin layer to obfuscate the underlying password text: http://www.nirsoft.net/utils/bullets_password_view.html More secure systems always show 8 bullets regardless of how many characters the password actually has and only provide limited feedback when hitting a key without allowing to see the number of chars in the password. Not showing anything is certainly more secure than any other method of providing user feedback, so I agree that we should not make this the default. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 13 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
FYI: prompt_toolkit can prompt for password input: https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/exampl... https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/exampl... It displays as asterisks and keeps all readline-like navigation. The second is an example of password input where Ctrl-T toggels between asterisks and all visible. Feedback is welcome (create an issue), but this probably will never become part of core Python. Jonathan 2016-01-13 11:36 GMT+01:00 M.-A. Lemburg <mal@egenix.com>:
On Wed, Jan 13, 2016 at 01:22:02PM +1100, Chris Angelico wrote:
I don't know... I'm about 35% convinced that obfuscating the password is just security theatre. I'm not sure that "shoulder surfing" of passwords is a significant threat. But the other 65% tells me that we should continue to obfuscate. -- Steve
On Wed, Jan 13, 2016 at 9:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
In some situations it's absolutely appropriate to not hide the password at all. (A lot of routers let me type in a wifi password unobscured, for instance.) But if you're doing that, then just keep the whole password visible, same as if you're asking for a user name. Don't show the one last-typed character and then hide it. You're quite probably right that obfuscating the display is security theatre; but it's the security theatre that people are expecting. If you're about to enter your credit card details into a web form, does it really matter whether or not the form itself was downloaded over an encrypted link? But people are used to "look for the padlock", which means that NOT having the padlock will bother people. If you ask for a password and it gets displayed, people will wonder if they're entering it in the right place. That said, though, I honestly don't think there's much value in seeing the length of a password by the number of asterisks. Have you ever looked at them and realized that you missed out a letter? But again, they're what people expect... ChrisA
On 13 January 2016 at 10:19, Chris Angelico <rosuav@gmail.com> wrote:
Personally, I frequently look at the line of asterisks and think "that doesn't look right" - it helps me catch typos. Also, doing things like deleting everything but the first N characters lets me retype from a "known good" point. I tend to get uncomfortable when I get no feedback at all, as is typical on Unix systems. But yes, it's about expectations, and it depends what type of system you typically work with. Although many, many people are used to seeing feedback asterisks or similar, as that's the norm on Windows and in many (most?) web applications. Paul
As in everything, it depends on the situation: https://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html The Security Now podcast has also expressed doubt on the practice in common cases. My take is that a few flags to control the behavior with convenient defaults perhaps, show_text=True, display_char=None, display_delay=0, and a Ctrl-T keybinding to toggle (as mentioned elsewhere). A good case could also be made for the most secure defaults instead. As long as the toggle keybinding were available it wouldn't be a great burden. This is a console-only solution, correct? So, Ctrl/Alt keys should be available. -Mike On 2016-01-13 02:04, Steven D'Aprano wrote:
On 01/13/2016 11:04 AM, Steven D'Aprano wrote:
This might not apply for people working from home, but at work I regularly enter my own password or passwords for other systems with other people intentionally looking over my shoulder (e.g. pair-programming, debugging, confirming error reports etc.) Should I ask them to look away from the screen each time? cheers, Georg
Regarding the issue of people looking at the user typing in the password. Unless the person looking is right next to the user, it doesn't really matter if they look at the screen, because if password masking is enabled they will only see the masking characters. If the person looking is right next to the user then that person can just look at the keyboard and the keys being pressed. Also the main issue here is that there should be a choice provided by the getpass function to provide feedback or not. On Thu, Jan 14, 2016 at 3:50 AM, Georg Brandl <g.brandl@gmx.net> wrote:
On 01/14/2016 11:07 AM, Muhammad Ahmed Khalid wrote:
Well, I can type reasonably fast. For Chris and anyone else who'd like to pretend not to know what I meant: The point is that these are *coworkers*, not *hackers*. They have no reason to go to great lengths to know these passwords. But at the same time, they're not theirs to know, and I'd like to keep them to myself, otherwise we could just use one company-wide password for everything. Having the password masked on the screen, where eyes will be anyway, is a good compromise to avoid needless interruptions. Georg
This discussion is kind of going into different directions and I want to bring it back to the getpass function. The original argument is that there should be a choice provided by the getpass function of getting feedback or not. Currently the getpass function does not provide any feedback and I just want to add the ability to make it so that I can get some feedback. Some one earlier mentioned that by default the function will not echo anything back and I totally agree with that. In fact I like that suggestion a lot. Only when the users* want feedback they can change the parameters of the function and add which ever character they want for masking. Please note that currently the first parameter of the getpass function is the Prompt. The second parameter can then be used as the masking character which can be None / blank by default. On Thu, Jan 14, 2016 at 4:08 AM, Chris Angelico <rosuav@gmail.com> wrote:
On 14.01.2016 11:29, Muhammad Ahmed Khalid wrote:
If you can make this work cross-platform, I don't think anyone would object to having such an option, as long as the default remains "show nothing" :-) For more complex password / key card / single signon / etc. functionality, I believe a PyPI installable package would be better. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 14 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
Georg Brandl wrote:
I have a solution! It requires a display capable of emitting light with selected polarisation. The password field displays the password in such a way that it can only be seen when wearing polariod glasses that are polarised in the correct direction. So a pair of programmers can wear glasses that let them each see their own password but not the other's. Bystanders not wearing any glasses would not see either of them. -- Greg
On 1/12/2016 8:11 PM, Muhammad Ahmed Khalid wrote:
You are debating the wrong issue. I work at home. I HATE Passwork Masking Security Theatre. Since I cannot reliably type 10 random hidden characters (or so sites tell me), it causes me endless grief for 0.00000% gain. If any of my passwords is stolen, it will, with probability 1.0 - epsilon, be part of one of the hacks that steal millions at a time from corporate sites. Epsilon would be something other than a stranger looking over my shoulder. http://www.zdnet.com/article/we-need-to-stop-masking-passwords/ PS: When UNIX decided to give no feedback, most people had one short easy-to-remember, easy-to-type password. Not a hundred hard to remember and type. --- Terry Jan Reedy
Sounds like this default should be user configurable as well, not only by the developer. Perhaps a function call to set the preference in PYSTARTUP? (or other precedent). A hotkey to toggle would be helpful for laptops, which tend to travel. -Mike On 2016-01-13 16:29, Terry Reedy wrote:
I HATE Passwork Masking Security Theatre.
participants (12)
-
Chris Angelico -
Ethan Furman -
Georg Brandl -
Greg Ewing -
Jonathan Slenders -
M.-A. Lemburg -
Mike Miller -
Muhammad Ahmed Khalid -
Oleg Broytman -
Paul Moore -
Steven D'Aprano -
Terry Reedy