Posted
by
timothy
on Saturday May 04, 2013 @08:24AM
from the dot-dot-dot-dot dept.

First time accepted submitter PAjamian writes "Maintainers of the Anaconda installer in Fedora have taken it upon themselves to show passwords in plaintext on the screen as they are entered into the installer. Following on the now recanted statements of security expert Bruce Schneier, Anaconda maintainers have decided that it is not a security risk to show passwords on your screen in the latest Alpha release of Fedora 19. Members of the Fedora community on the Fedora devel mailing list are showing great concern over this change in established security protocols." Note: the change was first reported in the linked thread by Dan Mashal.

... thinking they know what is best for everybody. Same stupid story again and again. A button or hot-key for those that want to see their passwords would be acceptable, but making it the default is not.

During the install process you're probably alone. I can't recall ever having done an install at the local coffee shop or on the bus. And during the install process is a good time to actually see the password.

The rest of the time though, it should be a hotkey as there's no point in masking the password if there's nobody in the room with you, I suppose there might be cameras, but if you're in public you should be assuming that somebody is looking over your shoulder. Even TrueCrypt offers the ability to unmask the passphrase if you wish.

As long as you must take any active action to display the password I'm fine with it, but if you give me a password field I'm going to assume by default that it won't be echoed back to me in plaintext and I'd consider anything else an obvious bug. It doesn't really matter that in this particular case you almost certainly don't need that protection, it breaks the whole user expectation for password fields in general. It's like if your car would detect there is no traffic so there's no point in blinking the turn signal because nobody would see it, in practice I'd just think my turn lights are broken not that it was "smart". And there's a lot of hand-waving to justify this complicating simplification.

There's little or no point in masking the password. Unless you're choosing stupid passwords or having a huge number of chances to guess the password it's not going to make much of a difference. With a properly 10-20 character password that's actually mostly random people are not going to guess that based upon seeing it one time. At least not without them having some sort of savant ability to memorize random strings of characters.

Checkbox or hotkey doesn't really make much difference, either way it should be

Wanna bet? I have inadvertedly trained myself to have photographic memory because I have had to type in manually thousands of service request numbers (which also contain letters, dashes) from screenshots or other machines. I can easily remember a 20-character string if I look at it for exactly as much time as you need to type it in, for enough time to allow me to write it down.

I'm sorry, but that is not a common ability that you're likely to encounter in the workforce. And generally service numbers aren't random anyways. They may appear to be random, but they're not, usually they're designed around a scheme that's only meaningful to people who use those numbers on a regular basis.

Except we're living in a world where almost everyone has a discrete camera built into their cell phone, and we may have to deal with things like Google Glass, of which later versions will no doubt become increasingly discrete.

Those of us who don't jerk off to how longer our passwords are, don't use 10 digit passwords.

I say this as someone who has written more cryptography software than you've even used.

10 digit passwords are fucking stupid. I'll just bash your head in rather than trying to brute force your password. I assure you, you will give it up FAR faster than anyone can brute force it. Same is true with 6-9 character passwords. I'll have found you and bashed your head in years before the password would be brute forced.

I don't think arrogance means what you think it means as I haven't demonstrated anything to that effect.

Whilst your comment is marginal troll, I will point out in the majority of cases the sensitive nature of any project wouldn't be a bearing in the choice of creating your own data center, that is just absurd.

Also, in the UK the B2B sector of hosting is a cut-throat arena just like most heavily invested sectors. I'm sure some of our competitors would relish at the opportunity to put a spanner in the works t

Because corporate offices and many small company offices are notoriously lacking in privacy and the only time there's 'nobody in the room with you' is if you're doing your installations on christmas eve.

Having the (Fedoras) install process work different than basically everything else is a bad choice in itself. And changing everything else would be utter idiocy; there are many cases like classes, presentations, user assistance, etc, etc when passwords are entered with observers watching the screen. One would basically have to move to one-time passwords to bypass the issue.

Needlessly displaying passwords without significant compelling reasons is simply atrociously bad design. The only time it is ever even remotely justified in common practice is when very, very bad input devices make it difficult to know which character actually got entered.

Is double-typing the password blind not enough? Even then, showing the password in plain view should be purely an option.

If you still have to type their passwords twice even if they are in plain view, there will still be problems with people making typos and just copy-pasting them to the second field without noticing (especially with longer and more complex passwords). Even if not everyone uses the copy-paste method, people will still possibly make a typo in one or both password entry fields... again, usi

My native language uses additional characters in addition to the ASCII ones. When I want to write in my language, I switch the keyboard layout so the additional symbols are in place of the number row. So, I can type the password and it will match, but later when I try to type it with the default layout on, it won't match if I used the number row keys when creating the password.

When I type somewhere else, I can immediately see that I'm writing nonsense because of the wrong layout and just switch it. I don't

That's an interesting idea. Everybody already warns if you have capslock on while entering a password. They could just change the warning to "Your password will be displayed in plaintext," and ignore the actual capslock (assuming that's possible.)

Some of us actually use CapsLock to invert the case of part of the password. I'd scream loudly if you sabotaged it. I've had the displeasure of typing some code on a Chromebook, and the key being diverted for an useless function is a pain.

I'm sure it is. I was actually just attempting to make a smartass remark about the need for a CapsLock warning on a password prompt (doubtless encouraged by the common tendency to forget the key exists). I think, perhaps, my smartassery should have been more direct, or maybe just more clever.

A good approach to the problem I've seen is masking the password except for the last character entered, put a timeout on that character (5-10 seconds), then mask it too. It lets you see what you've typed in, and you're no more at risk than someone just watching you type the password.

From a Anaconda GUI manual install process, it seems silly to ditch very basic password blackout + back-end entry validation to make sure both password and retype fields match. Was that too much to maintain?

From a Kickstart perspective, I'd say it's even 'less' secure because you can hard-code plain-text useradds in %post, grub passwords, AND more importantly, the root password itself. Not to mention, reveal a boat load about your hardware/network infrastructure that can be a lot mor

This is what happens when hipster UI developers from the mobile and web world come into the Desktop and Server world and think they are the shit. WTF? The Fedora community seems to have gone apeshit insane in recent years. First their stupid nonesense about moving/bin to/usr/bin, now this. It wouldn't be much of a problem if Fedora was an obscure experiemental distribution, but its not. Its a feeder of ideas and technology for one of the most widely used server distributions in the world. These developers

The log-in and sign-up pages on Phil's Hobby Shop have a "Show password as I type" checkbox. Is this what you were looking for?

As a MacOS X developer, the developer can mark text entry fields as "password". A major effect of this that other applications (like external spelling checkers, for example) don't have access to what you are typing. The other effect is that the input is hidden.

At the moment, you can't have a password field that gives protection against malware that could be on your computer, _and_ at the same time displays the password. Only one or the other.

Yes. I'd make the defalut the other way, but it should definitely be user selectable. Different circumstances call for different options, but I don't think making the initial password entry unreadable is a good choice in most circumstances.

Actually, for my setup I'd prefer that it almost always be readable, as there is no "caps lock on" indicator on my keyboard, and I rarely need to worry about shoulder surfers. (As in probably less than once a year.) But I have certainly observed other circumstances where that could be a concern.

OTOH, perhaps a default "password unreadable" is reasonable. Most people will never change the default, and won't think about the problem unless they do. But it should definitely be user selectable.

It's only in cleartext during installation, and only while the password field has focus. This is hardly something to get up in arms about, unless you regularly re-install your OS in front of a crowd.

Why not a choice? What's wrong with a button that says, "Unmask Password"?

And, sorry, but when developers decide what's best for me, that absolutely IS something to get up in arms about. Maybe I do install my OS in front of a crowd. Maybe I'm installing a real world system at a company that with a policy that says all systems must have the same password in front of people as part of a training course or at a cubicle next to someone who has not business knowing the password.

Why not a choice? What's wrong with a button that says, "Unmask Password"?

That's not a terrible idea, but I would be very careful about implementing it. The problem is that it *can* be worse to have a security measure be in place "sometimes" or "most of time" than to not have it in place at all. If password masking is common enough that people assume it will be there, then they'll rely on it, get a sense of security from it, and let their guard down. Then they may type their password out in an unmasked field without noticing in time. People tend to type their passwords out qu

I'll tell you what it works for - short passwords. I have some systems with 36-character keys (oh, right, passwords) and if they're masked and I'm all alone in a data center (or on remote, more likely these days) it's terribly frustrating since I'm not a perfect typist. Yeah, I can slow down and do it right (I don't have a neurological disorder, though some do) but being able to do it fast and have ac

I don't think it is the end of the world, I think it is more about expectations. I haven't seen the screen in question but I would probably be fine with it as long as it had a warning that the password would be displayed.
Suppose I am installing a virtual machine while sitting in a shared space or while sharing my screen on a projector. I go type that password in with the expectation it would be hidden and next thing you know, everyone knows my password.
I suppose you could say I'm a bad person for usin

What's more if you're setting individual admin passwords at install time you're doing it wrong. There's tools and techniques for dealing with this sort of thing that would be much more time efficient. Perhaps focusing on the real issue that you're not doing it right would be more efficient than demanding that everybody else suffer because you can't be bothered to set up deployment tools correctly.

That's equivalent to saying that if you do an install from the keyboard you're doing it wrong. There's puppet and a pile of other things to avoid manual installs, but sometimes it's handy to go through an install process instead of just churning out identical systems. Also as for "individual admin passwords" - sometimes you do want to give people development boxes or whatever where they know the root password but you don't want them to have root on other machines. Most of the scientists in my workplace k

In my case it's for people that are capable of a full reinstall if they find there is a different linux distro that better suits their needs (which a few have done without needing any help) and for developers that want to beat things until they break. They get a different root password to the servers, other desktops etc, and for some stuff even a different subnet. It's a little different to giving it out "willy-nilly" and given them nice safe VMs doesn't help when they want to muck about with hardware as

If you're using the appropriate tools for doing this sort of thing, why do you need the password to be visible?

See, works both ways.

The real issue is that when the end user needs to input a password it simply should not be visible by default as there is no way to tell if the user is in a situation where the password can be observed during input. As the user cannot be expected, without major flashing red alerts all over the screen, to assume that the Fedora installer will work different from close to every o

Not as easy if you use a more optimized keyboard layout during installation that requires far less finger movement, since most of the keystrokes would end up on the home row... plus you'd have the added benefit that no key they see being pressed is actually what it appears.:P

Of course, while somewhat-serious, this doesn't really apply in the context of this thread because the original posts were talking about business installs. I guess it's still possible, you'd just have to change the default keyboard la

Just look over your shoulder before entry.I've been stung by a fat finger problem before when I messed up entering the admin password for an "owncloud" area and the thing only lets you enter it once and it's masked. It was an annoyance and not a showstopper since having root lets you do pretty well anything to the applications running on a system (finding the password hash in the sql database and replacing it with another generated from a password I knew fixed it). It still took time and a visible field o

Do you really expect me to disconnect an employee computer, hull it up to my office, and reinstall there - just so I can have a standard local root password the other admins also know?

I sure as hell don't. I expect you to either push out a standard image or use PXE to boot the fucking thing and have it install the image that way with all of the employees files stored on the fucking server. As a small business owner, this is the method I prefer using with PXE boot being the 1st. I'll use a disk image for laptops unless it can be configured to PXE boot and download the damn image.

All this change does is force me to install from a master base image and remove the option for a normal install in the rare time I need it, which in reality causes me to never use their installer software more than once.

If you're doing it right to begin with, you wont be using the god damn installer anyhow as you should be either installing a standard image or using PXE to boot the system and install the fucking image.

All your bitching indicates to me is that you haven't a damn clue how to build a standard image or that you want to play with unsupported software. This affects only Fedora (RH's fucking Beta Branch) though if they incorporate the change in RH's supported version, they'll be dead within a couple of years if not sooner because of lawsuits and loosing most of their Government Certifications.

Before any of this will happen though, the shareholders will file suit and sue the idiot CEO/Chairman for violating "Fiscal Responsibility" as this is about the fastes way to kill Red Hat. Loose those Government Certifications and there isn't anywhere's in the world that a government will use their product. Hell give it enough stink and the shareholders may end up changing the Board and CEO for just that reason, gutting any compensation they would recieve (no golden parachutes).

It's a really bad idea to have the same local admin password on laptops that go out the door. Also for small businesses without a suitable site license each machine needs installing separately and an image won't pass Genuine Advantage.

"Do you really expect me to disconnect an employee computer, hull it up to my office, and reinstall there - just so I can have a standard local root password the other admins also know?"

That'd be a more appropriate place to do an OS install, but no: I expect you to lift your head and look around before typing, to see if anyone is staring at the screen. Because if there are other people in the room, and you're really that concerned that they'll be snooping at your root password, they can just as easily l

Because if there are other people in the room, and you're really that concerned that they'll be snooping at your root password, they can just as easily look at your hands on the keyboard.

To read the password from your hands, they need to watch you undetected during the whole password entry. Reading which keys people press is also error-prone and requires you to be very nearby to have full view of the keyboard. To read the password from the screen, you only need a single glance at it near the end of the entry process, and it can be done from further away.

Imagine a competition where two teams have to try to detect a password without being discovered, but for one team, the password is masked,

Oh please, Stupid users will always be stupid. And next level of stupidity will be that even the password typed is in clear text, the user will not recognise an upper case character and will think it is a lower case character and will call you up anyway.

Stupidity is always a race to the bottom. Somewhere you have to put a line and say: no, just learn how to do it.

Why make me go through all that extra work, effort, and time simply because someone is too lazy to add password masking code that has existed since the 60s?

They're taking the old code out, and writing new code with this feature, not leaving something undone. You're obviously fibbing about "other admins" Mr "Anonymous." I'd be embarrassed too if I was impersonating an admin. But your one mistake... admins can read.

In some environments, security is an issue. If it's network installable, then chances are they can get the kickstart/unattend/whatever file off the network. For most linux envs done right, the risk is disclosure of the/etc/shadow variant of the file severely mitigating the risk, but in Windows, you cannot use any sort of meaningful protection.

If you do it from stock media, policy may still prevent it from containing the media (e.g. high chance the technician won't take extra care and might lose media wit

In kickstart/autoyast/preseed, you can feed in the pre-crypted value. In windows, you must feed in the password. You don't have the option of, say, feeding in the NTLMv2 hash. Of course, NTLMv2 hash is far weaker than any of the modern crypt() strategies in a linux system.

I like the way Windows 8 addressed this problem. They added a button that looks like an eye on the right hand side of the password field to show the password as you've typed it. That seems like a better compromise than briefly showing the password characters.

How do you measure NIH? I'm not sure I see how you can put Microsoft is below GNOME and Ubuntu, although I'll be honest, they are all pretty bad about it...

Microsoft seems to be King of NIH to me, and GNOME is like Apple in their "our way or the highway" attitude about everything, but Ubuntu seems to be getting worse in several areas so it'd probably be too soon to judge them.

Bad idea. What if someone is in a library on a public computer and tries to log in, and just after they've entered their password, they wonder "Hmmm... what is that eye-looking thing?" Then they click it and--too late! A few people have already seen it. Oops! Add this "cloud computing" shit that all these companies are trying to force down our throats and you've got potential for problems.

But seriously though, it is a decent idea... just one that I'm sure is not infallible to situations similar to the

I think that this improves password usability and is a move to the right direction. Others should follow instead of making passwords even harder for the end users, the most insane counter examples are the websites that mask your username as well. However, there really should be a switch to toggle this behavior.

1. Apps should be aware of password entries, and should turn of mirroring monitors, projectors etc. during password entry.
2. Showing nothing of the password is bad. Some applications actually added random numbers of stars as you type, that is worse. Showing a single character is slightly useful. Dimming out a few characters is better.
3. People are very good at detecting that someone is looking over their shoulder.

Then applications for playing major studio movies would put a password box on the screen just to keep users from mirroring the video to more than one monitor without the movie studio's permission.

You are not thinking clearly. I said an application should disable display on external monitors or projectors while a password is entered. That means the application disables the monitor. An application for playing movies that _wanted_ to disable other monitors would just do that.

This ignores the fact that they wouldn't be able to convince me to rent movies on iTunes and pay them money if I couldn't watch them on my TV but only on my laptop.

Seriously speaking, that (plain asterisks) might be a surprisingly strong password. It would be very weak if someone saw your keyboard, but otherwise, who would get the idea to try that? Even the automatic password crackers might not be prepared to check that one.

It occurs to me that this definition could be modified so that a password all in a single symbol set always displays with only the * character, in addition to the new unmasking only kicking in after the first eight characters, if we wish to keep our fancy logic out from under the dim perceptions and loud scrutiny of the fangle haters.

The symbol would display as - only if different than the preceding character's symbol set. The first character would always display as *.

When you have increasing issues of password masking the best way is to have two input fields and train the user (this is an ADMIN anyway) to not copypaste.

Passwords should be long, they should be phrases, with alphanumerics, these are the hardest to crack passwords even if they have a lot of dictionary words. It's a lot harder to crack a 10 word phrase then a 12 letter pure alphanumeric that someone has to right down to remember.

Regardless of whether an idea is good or bad, you should not change decades-old conventions lightly. The proper thing to do at this time is to mask by default and have a checkbox nearby that lets the user choose to show the password.

"... decided that it is not a security risk to show passwords on your screen in the latest Alpha release of Fedora 19..."
Security risks is not something that can be "decided" by somebody. There are always risks and showing the password on plain text is certainly more risky than masking it. Or are there some really awesome benefits for showing them in plain. No. Because noone expects that, so both usability and security suffer.

If you are following standard security protocols. Most people are up in arms about this in the work place, but if you are following standard protocols at a work place, then it would not matter. An OS is always installed in a non-production network, with a different root password (typically the development network root password as it is distinct from production). Then the new OS is patched, configured with check lists, connected to LDAP servers (or what ever connections you need). The last three steps ar

I don't know if you are sarcastic or not, but I for one am thankful for the maintainers of Fedora. Hear me out...

These days I have to type in passwords that are akin to random letters. I am ok with that. BUT it is BLOODY EFFEN HARD to type in the password into the text field. And if the text field hides the text it becomes annoying to have to input the data again. The problem is that I know my keyboard, but sometimes I have to type twice to hit the correct %^*( character. If I am looking at the keyboard and the screen at the same time things become confusing. Doing this two or three times becomes a royal pain in the arse!

I understand WHY you should not do this, but quite frankly there is theory and there is practice. And in an era of long obtuse passwords I am thankful!

Because many organizations have weird and bizarre rules for passwords that are not based on actual truth of what makes a secure password. My current favorite is 16! Characters, no words, at least 2 each of special characters, numbers, lowercase and uppercase letters. i.e. so long that NO ONE can remember the things if they're truly randomized. Although they're supposedly switching that particular circumstance over to token-based.