Fedora's invisible passwords and visible squabbles [LWN.net]

By Jonathan Corbet
May 8, 2013

The relative quiet recently experienced on the Fedora development mailing list felt a bit like the calm before the storm. And, indeed, the storm duly arrived in the form of a heated discussion over the proper behavior of the password forms in the Anaconda installer. When the dust had settled, the status quo ante prevailed. But some interesting governance questions were raised in between.

The problem

After the Fedora 19 alpha release, the installer developers decided to stop masking the passwords supplied by the user during the installation process. Passwords only remained visible for as long as the keyboard focus remained on the relevant input box; as soon as the focus moved on, the password would be masked. But that still left the password visible for an arbitrary period of time to anybody who chose to look.

Some users, suffice to say, were unamused. A bug report was filed — and promptly closed:

This is working exactly as it is intended. The passwords are only visible while they are focused. As soon as you unfocus a field, the password is hidden. This is a pattern that is becoming more and more widely used, and it makes sense. Hiding the password as you type doesn't actually do anything for security, as anyone watching your monitor could just watch your keyboard instead.

The above-mentioned unamused users were, strangely enough, equally unamused by this response. The bug was reopened, and the massive mailing list discussion was launched. The arguments covered whether it ever made sense to show passwords in the clear, whether passwords still make sense at all, and more. The new behavior had few defenders, a trend not helped by the near absence of the Anaconda developers from the discussion. On May 6, the change was reverted with no explanation. At that point, naturally, the discussion was done.

Heard in the debate

While there was a lot of talk about the security issues associated with the clear display of passwords, there was also a lot of meta-discussion on how issues like this should be handled. Some participants, Matthew Garrett in particular, took issue with the tactic of reopening the bug entry:

I'm saying that if a bug report has been closed due to the change being a deliberate design decision, reopening the bug isn't going to change the fact that it was a deliberate design decision. The appropriate place to discuss deliberate design decisions is a forum where said decisions are made, ie not Bugzilla.

Anybody who spends any significant time reading bug tracker entries knows that they often host spirited debates about the merits of specific changes. These entries can serve as a focal point for a discussion of a particular issue that the relevant developers will have a relatively hard time ignoring. On the other hand, bug trackers can be painful places to hold any kind of detailed discussion. They tend to have all of the disadvantages of forum sites, without the polished interfaces and enhanced searchability that such sites provide. A desire to keep such discussions on the mailing lists — and to avoid using the bug tracker to bug the relevant developers — is understandable.

A few people tried to bring up matters of policy, claiming, understandably, that policies are a big part of what distinguishes a distribution from a random collection of software. Fedora does not appear to have an explicit policy on how password forms should behave. Perhaps it should: it would be better if such forms behaved consistently throughout the distribution rather than surprising users with occasional novelties. Eric Sandeen suggested that Anaconda's unique role in the distribution should maybe subject it to more scrutiny than other packages, asking "How much of the Anaconda team's job is it to set Fedora OS policies and behaviors, vs. to implement them?" He pointed out that a decision by the Anaconda developers to change the default filesystem used with new installs would probably not be seen as an Anaconda-only matter, for example.

It was suggested that the issue could be forwarded to the Fedora Engineering Steering Committee (FESCo) in an attempt to force the change to be reverted. FESCo member Kevin Fenzi expressed the low level of enthusiasm most participants seemed to feel for that approach:

If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?

Fedora, arguably, does not defend the independence of its package maintainers as fiercely as, say, Debian does. But a developer's package still tends to be their castle; even those who were opposed to this particular change were, for the most part, unwilling to try to revert it by force. As a community, we remain disinclined toward dictating instructions to our developers.

The discussion clearly covered a number of ways in which this particular technical decision should be debated and decided. The one thing it did not do, unfortunately, is provide any indication of how the decision was made to revert the password change. So a discussion that might have led to a better understanding of how security-related decisions should be made within Fedora ended up, instead, with the possibility that the developer involved simply backed out the change rather than face the mob. That gives the Fedora community no guidance on either policy or the best way to handle technical disagreements; as such, it represents a missed opportunity. Passwords, arguably, should be invisible, but policy decisions usually belong in plain sight.

to post comments

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 2:10 UTC (Thu) by kfiles (subscriber, #11628) [Link] (8 responses)

I'm partial to the password-entry boxes that hide my password by default, but provide a "show password" checkbox, in the event that I'm using a really long, complicated password on a device with a crummy keyboard, and with no one around.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 4:53 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (6 responses)

I would add to this that nothing should be shown, not even the asterisks (or circles or whatever), when the checkbox is not checked. But this is not a strong preference; I've never heard of somebody being able to crack a password given just the length, but unable to crack a password without it.

As a dvorak user, I often have times when I'm not sure what the keyboard mapping is -- such as when I'm setting up a VM from another machine, and the keyboard is double-mapped from qwerty to dvorak -- and it would be much more convenient (and more secure!) to hide the screen than to have to draw translation tables and write out passwords on paper.

So, it would have have been great for Fedora/anaconda to show some innovation on this point, and at least have a system-wide policy. I can dream...

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 7:12 UTC (Thu) by bosyber (guest, #84963) [Link]

I agree, similar issues turn up for me in switching between US/Dutch and German keybord mappings; and some keyboards have an easy to trigger caps lock without indication too. Guests with weird keyboards/me visiting friends, with no WPS, but needing wifi come to mind as well.

Not showing anything but having an option to verify what was typed is quite useful. If you remain in a save environment while that option is available, that is; of others can acccess the option, it is a potential problem, though not so much in that wifi router case where it is a shared secret. Remaining at the keyboard until you typed the password seems like a decent workaround in anycase.

About password length

Posted May 20, 2013 17:27 UTC (Mon) by man_ls (guest, #15091) [Link] (4 responses)

I like how Lotus Notes shows a variable number of Egyptian hieroglyphs when typing your password, so nobody can guess the length of the password. Let me clarify: what I really like about it is making fun of this utterly absurd feature, no doubt born out of some manager's primeval fear of passwords so that any bit of leaked information (such as the length of the password) was a danger to the whole system. And the Egyptian hieroglyph was undoubtedly a touch of madness trying to add more "security by absurdity".

I have not heard either of password length being used to compromise the system, but that is not my thing so I am not completely sure about it. The state of the art seems to be: show keypresses as round balls ⚫, then when displaying a previous password show a predetermined length of round balls ⚫⚫⚫⚫⚫⚫⚫⚫ (not the actual password length).

About password length

Posted May 20, 2013 21:32 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

The idea that hiding password length was just a managerial decision is absurd. standard unix logins have been doing that for several decades and that was designed entirely by developers.

About password length

Posted May 20, 2013 22:24 UTC (Mon) by man_ls (guest, #15091) [Link] (2 responses)

I am ready to entertain the notion that hiding password length was a developer decision. What I cannot accept under any circumstances is that the hieroglyph bit (which is what really gets to my nerves) did not come from a deranged manager.

About password length

Posted May 20, 2013 22:59 UTC (Mon) by dlang (guest, #313) [Link]

ohh, there are plenty of deranged developers out there. I have no trouble believing that some developer thought that was 'neat'

About password length

Posted May 21, 2013 1:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Well, sort of. In the Lotus notes case, IBM managers encouraged developers to come up with "creative" ideas everywhere to increase the patent portfolio and developers came up with such brilliant ideas. It is not just IBM that does this however.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 18:53 UTC (Thu) by debacle (subscriber, #7114) [Link]

Yes, not showing the password by default makes sense, because sometimes people might be able to watch a screen, but not necessarily your keyboard. Think you are speaker in a conference and hundreds of people see your password, but nobody your keyboard. Provide for a "show password" function is useful, e.g. when assuming the wrong keyboard layout.

E.g. network manager applet dialogues do exactly that for WiFi, many web sites do this etc.

Do it everwhere or nowhere

Posted May 9, 2013 5:57 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

Hiding passwords doesn't make sense any more? Fine, then change it - across the whole distribution (or at least in 80 per cent of places - the common password entry widgets in GTK, Qt etc).

What doesn't make sense is for a supposed matter of policy to be decided unilaterally by the Annconda developers and applied only in that package.

Do it everwhere or nowhere

Posted May 9, 2013 12:34 UTC (Thu) by misc (subscriber, #73730) [Link] (3 responses)

I think that's "hiding when you create a new user and when a error mean that you have to reinstall unless you know the trick to reset the password".

The idea was not to be applied to every possible entry box.

Do it everwhere or nowhere

Posted May 16, 2013 12:42 UTC (Thu) by robbe (guest, #16131) [Link] (2 responses)

Doesn't entering a (hidden) password twice solve this nicely?

Showing the password will not help if you don't re-check the password visually.

Do it everwhere or nowhere

Posted May 16, 2013 19:05 UTC (Thu) by adx (guest, #87945) [Link]

From experience, no. I've fat fingered a password twice more than once.

Do it everwhere or nowhere

Posted May 17, 2013 12:22 UTC (Fri) by Wol (subscriber, #4433) [Link]

And it's no use (as was pointed out elsewhere) if the keyboard mapping isn't what you think it is.

Double entry confirms the accuracy of your typing. It doesn't fix the problem of the keys not being what you think they are.

Cheers,
Wol

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 7:37 UTC (Thu) by MortenSickel (subscriber, #3238) [Link] (17 responses)

"Hiding the password as you type doesn't actually do anything for security, as anyone watching your monitor could just watch your keyboard instead. "
Please tell me this is a fake quote! "as a person who has trained reading what someone types by watching the keyboard and being situated with a clear view of the keyboard culd just read your keyboard instead." would make sense.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 10:04 UTC (Thu) by hummassa (guest, #307) [Link] (16 responses)

for a value of "training" = "a couple of hours", maybe. Really, unless you are a star typist or your password is really long or complex, anyone watching your keyboard can read what you typed.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 12:45 UTC (Thu) by drag (guest, #31333) [Link] (12 responses)

Or they could just use their smartphone to record you.

Really though the * password thing survives mostly as just a convention rather than any sort of rational thought process. It's not done because it actually improves security, but because it's always been done and it probably has something to do with security. Lots of time it make sense, but other times it doesn't.

The most important thing is to use secure passwords and hiding passwords from view just means that it makes that much more harder to use good passwords.

At work I would hate to have my passwords visible because it's busy and people are always wondering around. It's important to maintain some baseline security policy in that sort of situation.

At home I would LOVE to have my passwords visible because I use long passwords and it's irritating to have a typo and re-type in the password 4 or 5 times and get locked out of a account.

Locking accounts on bad passwords, however, is just idiotic and needs to go away. Whoever thinks that is a great idea needs a severe clubbing with a clue bat.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 13:27 UTC (Thu) by Funcan (guest, #44209) [Link] (4 responses)

Locking an account on /enough/ bad passwords makes perfect sense, otherwise dumb brute forcing starts to become too easy - assuming you can extract a list of login names from somewhere, trying a couple of hundred most common passwords on all of them has a good chance of getting a few hits (birthday paradox bites you in the ass).

If you allow complex passwords and have reasonably well educated users, then locking after 10 or 20 wrong attempts, rather than 3, might start to make sense. Locking for a sort time rather than indefinitely might start to make sense too. Fail2ban short term IP blocks might also make sense too

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 15:18 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (3 responses)

> If you allow complex passwords and have reasonably well educated users, then locking after 10 or 20 wrong attempts, rather than 3, might start to make sense. Locking for a sort time rather than indefinitely might start to make sense too. Fail2ban short term IP blocks might also make sense too

If you had said 100 or 200 attempts, I'd agree with you. No human is going to accidentally mess up a password that many times, any bad guy who can guess the password in fewer tries knows too much anyway (you already have compromised security), and brute forcing is completely blocked.

Alternately, blocking unilaterally for 15 or 30 seconds after every bad attempt would also prevent brute-forcing, as well as be extremely irritating to human bad guys.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 16:36 UTC (Thu) by drag (guest, #31333) [Link]

All the difference between have 3 tries and 200 tries is that it takes a attacker a few seconds longer to lock out all the users and administrators. ;)

Fedora's invisible passwords and visible squabbles

Posted May 15, 2013 14:14 UTC (Wed) by hummassa (guest, #307) [Link] (1 responses)

Apple does the right thing with respect to this: throttle exponentially against the number of tries. 10s, 30s, 1.5min, 4.5min, 13.5min, 40.5min and so on.

Fedora's invisible passwords and visible squabbles

Posted May 16, 2013 13:21 UTC (Thu) by callegar (guest, #16148) [Link]

No, not at all. It is quite irritating when you leave your ipad around to see that someone had fun in locking it for almost 15'.

Really, this does not make any sense. To avoid brute force attacks a few seconds are more than enough: 100000 trials * 36 sec = 3600000 sec = 3600h = half a year > average time between recommended password changes.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 15:41 UTC (Thu) by mitr (subscriber, #31599) [Link] (6 responses)

I think it's exactly the other way around: systems should lock users out, at least for some time, on incorrect attempts; if they do, the passwords can be much shorter and easier to enter.

This is especially applicable to web applications, where every log in attempt is "online" and the lockout policy can be consistently enforced.

For passphrases that protect encrypted data at rest (e.g. hard disk encryption passphrases) or other systems that allow offline password cracking, the password does need to be long - however hard disk encryption is pretty much the primary such case, and even in this case a clever combination of hardware + software (e.g. a TPM-like device storing the actual key, that can lock the user out) might allow us to use short passwords.

(Note that long passwords are not necessary in web applications to protect against rogue administrators of the web application running an offline dictionary attack - the rogue administrators can just modify the web application to log the passwords in plaintext, so password length does not matter for protection against rogue administrators. It only protects against password guessing by third parties (and against people seeing and remembering a short password).

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 16:09 UTC (Thu) by andresfreund (subscriber, #69562) [Link] (2 responses)

> I think it's exactly the other way around: systems should lock users out, at least for some time, on incorrect attempts; if they do, the passwords can be much shorter and easier to enter.

> This is especially applicable to web applications, where every log in attempt is "online" and the lockout policy can be consistently enforced.

Making it extremely easy to lock somebody out of their account. Pissed about somebody? Enter 10 times the wrong password on their email account's web interface. In contrast to protecting my account with a good password I can't do anything to protect my account to being temporarily blocked in this case.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 17:32 UTC (Thu) by mitr (subscriber, #31599) [Link] (1 responses)

Teaching the lockout logic about existence of IP addresses (which more or less can't be forged with TCP), to be smart about treating attacks from a single IP address / small IP block / botnets different, and to alert human administrators about unusal cases should not be that hard.

It would be nice if every application didn't have to invent this from scratch, sure - are there any libraries that can already do this?

Fedora's invisible passwords and visible squabbles

Posted May 10, 2013 10:18 UTC (Fri) by k8to (guest, #15413) [Link]

Well when the implementation involves logfile scraping (common) then you sure can forge IP addresses.

just log in as the username "jrodman]: 1.2.3.4" or similar.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 16:34 UTC (Thu) by drag (guest, #31333) [Link]

> I think it's exactly the other way around: systems should lock users out, at least for some time, on incorrect attempts; if they do, the passwords can be much shorter and easier to enter.

At any place I worked at that had such password policies I could lock out EVERYBODY in the entire corporation with a simple shell script.

How would you like it if everybody got locked out of their accounts? CEO, IT, business, etc etc. Every administrator, every user.. all at the same time? Say... right when everybody gets in in the morning. Something like that can easily cost a business tens of thousands of dollars.

It is effectively building a denial of service vulnerability into your password policies.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 17:58 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

> I think it's exactly the other way around: systems should lock users out, at least for some time, on incorrect attempts; if they do, the passwords can be much shorter and easier to enter.

I think the most sensible thing to do is requiring a CAPTCHA after a few wrong attempts. It will keep out most bots and slow down human guessers, while just being a small hassle for legitimate users.

Fedora's invisible passwords and visible squabbles

Posted May 13, 2013 8:17 UTC (Mon) by micka (subscriber, #38720) [Link]

> while just being a small hassle for legitimate users.

A small hassle ? This things that consistently proves me that I am a bot ?

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 12:45 UTC (Thu) by pboddie (guest, #50784) [Link]

Well, what this change apparently does is to require administrators to tell other people to leave the room, rather than not stand immediately behind them, when they're setting up a system. Maybe administrators who had any unprivileged users in the room when previously setting up systems will now be told that they were "doing it all wrong".

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 14:33 UTC (Thu) by AndreE (guest, #60148) [Link] (1 responses)

It's much easier to notice someone with a camera pointed at your keyboard than someone glancing at your screen

Fedora's invisible passwords and visible squabbles

Posted May 10, 2013 3:29 UTC (Fri) by faramir (subscriber, #2327) [Link]

That was true in the BGG era. Now that we are in the AGG (after google glasses) era, not so much.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 15:07 UTC (Thu) by Baylink (guest, #755) [Link] (5 responses)

There are two separate questions here, as far as I can see:

Is a change in password-entry-handling warranted? And is Anaconda suficiently "core" to Fedora that that question should drive or be driven by a distribution-wide policy, as opposed to being a "preserve the desires of the package maintainers" issue?

My inclination on the latter is "yes", though admittedly, I haven't used Anaconda since RH8; you have no choice about the installer, the distribution release manager picks that for you; I can't think of anything else -- even the kernel, about which you sometimes get a choice -- that is so core to a distribution as its installer package. That being the case, I don't think it at all unreasonable to construe that as a core package, and expect that policies it sets are distribution wide policies, rather than the whims of a specific package maintainer.

The more fundamental question, though, is the first: is a change in default password-entry visibility policy justified? It is my understanding that one of the driving forces behind this change was an opinion put forth by security consultant Bruce Schneier.

Bruce has recanted that opinion in later writings, so to the extent that it was such a driving force, it's clearly time to reconsider. That said, it's substantially easier -- an order of magnitude, if not two -- to shoulder-surf off a display (think "binoculars", if not "HD security webcams" "Freeze! And Enhance!" :-).

I personally tend to like to check that box that says "show my password". But *I want the box*; *I* know if someone is near me, or if my monitor is visible from useful angles; the computer... so doesn't.

IMO: The box should be there, and by default, it should be unchecked. Those who note that asterisks are bad are also correct; knowing the length of the password substantially reduces the effort to crack it.

It's possible such a single-use password is not the low-hanging fruit, but we do know what makes it *less* secure, and there's no sense volunteering to do those things.

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 19:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Those who note that asterisks are bad are also correct; knowing the length of the password substantially reduces the effort to crack it.

Knowing that there is a password entered in the box is nice to know however. Why not make the password field 2–3 characters wide and show the asterisks/dots/whatever (like the gnome-keyring dialog)? I believe KDE also had the option to show 3 asterisks for each character (to help overflow a larger box and that you quickly break the count-at-a-glance limit).

Fedora's invisible passwords and visible squabbles

Posted May 9, 2013 19:19 UTC (Thu) by Baylink (guest, #755) [Link]

The 3-asterisks thing is probably the most useful compromise, though it's hard to see them move; I would use three *different* characters, like:

*#%

That would make it much easier to see the motion as each key is pressed.

Though, as I say, I tend to just prefer double clicking in the "show password" checkbox; the quick flash is enough, generally, for me to confirm I typed it right.

Password length

Posted May 16, 2013 12:56 UTC (Thu) by robbe (guest, #16131) [Link] (2 responses)

> Those who note that asterisks are bad are also correct; knowing the length
> of the password substantially reduces the effort to crack it.

Depends on your definition of "substantial". For the cases I computed, and that I consider relevant, the effort reduction is not even half. Not what I would call a good safety margin.

The more important advantage an attacker gains by seeing the (approximate) password length is being able to weed out "too hard" passwords, and just attack accounts with easier ones.

Password length

Posted May 16, 2013 14:20 UTC (Thu) by robbe (guest, #16131) [Link]

Oops, I miscalculated. The added effort for the attacker if she does not know the password length asymptotically approaches (b+1)/b, where b is the size of the character space. Worst case for the attacker is a numeric password, which adds only a measly 11 % of effort. Lower-alpha gives 4 % more, etc.

Password length

Posted May 16, 2013 14:46 UTC (Thu) by anselm (subscriber, #2796) [Link]

Way back when, VAX/VMS used to output either one asterisk or three for every password key pressed, on a random basis. This had the advantage of letting the user know that their keypress had registered, without giving bystanders a good clue how long the password in question actually was.

Fedora's invisible passwords and visible squabbles

Posted May 10, 2013 11:14 UTC (Fri) by ras (subscriber, #33059) [Link]

> Anybody who spends any significant time reading bug tracker entries knows that they often host spirited debates about the merits of specific changes.

We all have have our favourite bug reports I guess. Googling "bucket full of cocks" gives a Linux disto bug report as it's top hit. Bonus point for guessing which distro before googling it.

Fedora's invisible passwords and visible squabbles

Posted May 18, 2013 2:25 UTC (Sat) by heijo (guest, #88363) [Link] (5 responses)

It looks like other Red Hat departments are learning UI design from the highly successful GNOME 3 team!

However, they still have a long way to go: the correct way to deal with bugs and other feedback from pesky users is to tell them to fuck off, close as WONTFIX and NEVER reconsider your changes.

Only this way users can be persuaded to go away, allowing developers to freely express their talents unburdened by them, for the best results possible.

Enough

Posted May 18, 2013 12:57 UTC (Sat) by corbet (editor, #1) [Link] (4 responses)

Do I really have to point out how silly and pointless this kind of drive-by attack is? If you don't like GNOME, you are lucky in that there are a number of alternatives to choose from. Could I ask, please, that you pick one and refrain from this kind of trolling here?

Enough

Posted May 21, 2013 14:58 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

It's not true, anyway. GNOME may ignore its userbase but its developers claim to want users. If you want a team that actually says that it doesn't want users, and is willing to go as far as throwing out core developers to further that goal, you have to look at the XFree86 project.

Enough

Posted May 21, 2013 17:06 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Don't forget OpenBSD.

Enough

Posted May 21, 2013 18:40 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

OpenBSD often ignores its users, but is it actually actively antagonistic to them? I don't know...

Enough

Posted May 21, 2013 20:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Oh, but it does.

There was a message from Theo to the tune that OpenBSD is developed for the needs of its developers primarily. And if some users find it useful for them - that's their problem.