Bug 1468754

Just a note from the Product Security perspective: autocomplete off actually weakens security significantly as it blocks password managers. If someone doesn't want to use a password manager, that's fine, they can also disable the "remember passwords" for the Sat 5 site as needed, and Group Policy is available for virtually all browsers now so this can be centrally enforced as needed.

As for the scanning tools that generates false positive on this, that's unfortunate. There are a lot of tools that do scans based on a simplistic interpretation of the data like HTML forms, package versions (ignoring backports of CVE fixes) and so on that generate false positives, and broadly speaking Red Hat can't really fix that. 

Also a note: some browsers are starting to ignore autocomplete off because it does more damage than good with respect to password fields, so this is a very moot point moving forwards. 

You could consider an RFE to add an optional switch for autocomplete off in the web forms, but that wouldn't be a security vulnerability, or even a security hardening feature really, it would be more of a compliance fix to make poorly written tools stop complaining, and it wouldn't even work with some modern browsers since they ignore it.

Closing this as WONTFIX because it's actually something that would generally not be effective and would actually make security worse in some situations.

> autocomplete off actually weakens security significantly as it blocks password managers. 

You have to help me out with this line of reasoning. Let's say my password is "greg".

Method one - There's no autocomplete.  I login to Satellite and I have to spell out greg in the password field.  Maybe I have to look it up in a password manager, but I still need to enter it.

Method 2 - supposedly *more* secure. I login to Satellite and look up my password in the password manager.  I see it's "greg".  I type "g" in the password field and Satellite conveniently fills in the rest.

Explain to me how method 2 is more secure or what I'm missing?

- Greg

Method 1, "the password doesn't get filled in", is only actually reliable if *the browser has never saved the password*. If the browser-user has told the browser to remember the password, then in most modern browsers, setting autocomplete='off' will have *no impact* on the field - it *will* get filled in, because the browser knows it.

Method 2 is "using a password manager". You go to the satellite login, and login and password get filled in because your password manager knows them, and because you're using a password-manager, your password isn't 123456! on every site you visit, it's a random site-unique 18-character-string, and because you're using a pwd-manager, it's in a strongly-encrypted keystore with a unique master password, and the password is only available if you've logged into your password-manager, instead of being easily-visible from the browser's "settings" page.

Current best-security-practice is, "it's better to support password-managers that store strong, unique, passwords, and auto-fill-them-in, rather than rely on trying to hide the bullshit ones that humans come up with and then use on multiple sites because people are terrible at remembering passwords".

The whole "but someone might come along and use the browser when I'm not there" ignores the gaping sucking chest-wound of a security hole, which is 'someone has physical access to a system that I do system management from'. Right now, it would take one of the Bad Guys less than 30 secs alone with your unlocked system to compromise it in a way that would record every keystroke you make on it (and note that autocomplete foils some of the less-sophisticated recorders, because *there are no keystrokes involved*).

The net for me, as someone who was a security architect in a previous life, is that "appearance of security" is much, much worse than "knowing you have a potential exposure". If a browser knows your password well enough to fill it in, then trying to teach a web app to *hide that fact*, secures *nothing* - the password is there, available to the browser, a mouse click or two away. It's available, in the clear, no matter what the app tries to make you believe. "Oh no, I stored this password?!? Crap, I better delete that RIGHT NOW!" is a much, much better state than thinking your password exists only in your head, when that is not true.

The only thing forbidding autocomplete accomplishes, is it teaches humans to have short, easily-remembered passwords. This is the worst possible security hole with passwords - easily-guessed, and usually multi-use, because remembering multiple passwords is even harder than remembering just one.

The fact that modern browsers *pay no attention to the autocomplete attribute* is just icing on the cake of "this isn't security, it's security theater".

See the discussion here, from the Mozilla developers

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion , section "The autocomplete attribute and login fields"

In any event - Red Hat Product Security has weighed in on this, and I will defer to them.

(In reply to Greg Scott from comment #6)
> > autocomplete off actually weakens security significantly as it blocks password managers. 
> 
> You have to help me out with this line of reasoning. Let's say my password
> is "greg".
> 
> Method one - There's no autocomplete.  I login to Satellite and I have to
> spell out greg in the password field.  Maybe I have to look it up in a
> password manager, but I still need to enter it.
> 
> Method 2 - supposedly *more* secure. I login to Satellite and look up my
> password in the password manager.  I see it's "greg".  I type "g" in the
> password field and Satellite conveniently fills in the rest.
> 
> Explain to me how method 2 is more secure or what I'm missing?
> 
> - Greg

To be clear is your concern that the Satellite 5 server is filling in the password? Because that's not what is happening here (I know it may be a silly question, but it's good to confirm).

> To be clear is your concern that the Satellite 5 server is filling in the 
> password?

That's what they're telling me - but the whole thing came from a required audit, and I'm told the auditing tools are all automated.  So there aren't people sitting down at a browser and recording results, it's automation looking at the dialog.

re: Grant - I like the passion.  I follow your reasoning - summarized by making the best of a bad password situation by inserting a password manager to enforce strong passwords and use autocomplete to fill them in. Your reasoning is well thought out, but does not convince me it's the right way to go.

Just one other comment - if I tell my browser to remember my password, then all the consequences are my fault.  The problem is pushing that autocomplete back into the product, which is pretty much telling every browser to remember the password, even if I, the admin, don't want the browser to remember the password.  Seems to me, if you turn autocomplete off, then I have the ability to use a password manager and tell my browser to remember it. But if you turn autocomplete on, then I don't have a choice.  My browser sort-of remembers it no matter what.

Since this is closed wontfix, I'll defend it as best as I can, even though I disagree with the choice.

- Greg

(In reply to Greg Scott from comment #9)
> > To be clear is your concern that the Satellite 5 server is filling in the 
> > password?
> 
> That's what they're telling me - but the whole thing came from a required
> audit, and I'm told the auditing tools are all automated.  So there aren't
> people sitting down at a browser and recording results, it's automation
> looking at the dialog.

Satellite doesn't fill in *anything* - the browser does. Which is why this is mostly-impossible to prevent, because the browser manufacturers aren't buying it.

> re: Grant - I like the passion.  I follow your reasoning - summarized by
> making the best of a bad password situation by inserting a password manager
> to enforce strong passwords and use autocomplete to fill them in. Your
> reasoning is well thought out, but does not convince me it's the right way
> to go.

Let's make something really clear here: this isn't *MY* reasoning. This is the currently-accepted-best-practices of the industry. I'm not the one, for example, that taught Chrome to ignore autocomplete="off" - Google did that. The link in my prev comment isn't my blog - it's the Mozilla developers-doc.

That I can't convince you, isn't a major issue, I'm just Joe Random Dev. It's that you remain 'unconvinced' by current best-practices of the entire security industry, that's mildly alarming.

> Just one other comment - if I tell my browser to remember my password, then
> all the consequences are my fault.  The problem is pushing that autocomplete
> back into the product, which is pretty much telling every browser to
> remember the password, even if I, the admin, don't want the browser to
> remember the password.  Seems to me, if you turn autocomplete off, then I
> have the ability to use a password manager and tell my browser to remember
> it. But if you turn autocomplete on, then I don't have a choice.  My browser
> sort-of remembers it no matter what.

There is no "turn autocomplete on". Here's the satellite code in question:

https://github.com/spacewalkproject/spacewalk/blob/master/java/code/webapp/WEB-INF/pages/common/fragments/login_form.jspf#L13

You will note, there is no 'autocomplete' attribute there. We inherit the default behavior of the browser.

Satellite, the app, does not 'remember' your password - the browser does. I can't stop that.

Satellite, the app, does not autocomplete this field - the browser does. I can't globally stop that, either - only occasionally, and for some subset of the current-popular-browsers.

Satellite, the app, doesn't even *ask* the browser to autocomplete - we take the default behavior of browsers. (It's your (the user's) browser, after all)

Satellite, the app, doesn't know anything at all about your login or password, until you hit  the "Sign In" button.

> Since this is closed wontfix, I'll defend it as best as I can, even though I
> disagree with the choice.

+1 to what Brant said above, it's entirely correct.

When I visit amazon.com to buy a book - my browser autocompletes my username, but  not the password.

When I visit any banking or credit card site - some autocomplete my username.  None autocomplete my password.  Not one.

When I visit https://access.redhat.com - I have to fill in a password.  It does not autocomplete.

When I login to the Wordpress websites I built, I have to enter the whole password.  No autocomplete.

I can fill this comment up with categories of websites I visit.  Not one website, not one, no matter what browser, no matter how many times I've used that same browser on that same website before, not one autocompletes a password.  Not one.  None.  Zero.

And I use lots of browsers, including Chrome.  Mostly Chrome these days.  I never tell browsers to remember a password and I advise anyone who will listen not to.

I am aware that apps tell browsers what to do and depend on browsers to honor their wishes.  I wasn't born yesterday.

But I have to wonder - if I'm going against best security practices as set forth by the entire security industry, and if Google modified Chrome to not honor that ignore-autocomplete setting, then why have I never seen a browser - other than Satellite - autocomplete passwords?

I just went to access.redhat.com, in a fresh browser that I had not used for anything else (Firefox 54.0 (64-bit) on F26)

First contact, no login/pwd (obviously). I log in, browser asks "should I remember this password?", I said yes. Log out.

Logging back in, type one character in the login field, browser hands me a pulldown with remainder of login name, I choose it, browser fills in login *and password*.

Inspecting page element, autocomplete="off".

Go to FF preferences, tell it "do not remember passwords", delete password.

Back to login page, choose login, password field not filled in.

Go to Sat5 login page using same browser, enter login and password, login.

Logout, go back to login page, enter login. No password filled in.

I'm not sure what to tell you.

While you were experimenting, I just read that Mozilla article you mentioned a couple comments ago.  Pasting in the last couple of paragraphs:

********

If a site sets autocomplete="off" for username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11).

If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet.

*********

That's exactly the behavior you described in your access.redhat.com experiment above.  That behavior is fine. You, the user, told your browser to remember the password and the browser did your wishes.  And you found the page element said, autocomplete="off".

That's the audit requirement for the Satellite password field.  Behave the same way as that access.redhat.com password field. Don't depend on the browser default, specifically turn it off.  If the user tells the browser to remember the password, then the user made a choice and deals with the consequences.

That's all I'm asking.

(In reply to Greg Scott from comment #14)
> While you were experimenting, I just read that Mozilla article you mentioned
> a couple comments ago.  Pasting in the last couple of paragraphs:
> 
> ********
> 
> If a site sets autocomplete="off" for username and password input fields,
> then the browser will still offer to remember this login, and if the user
> agrees, the browser will autofill those fields the next time the user visits
> the page.
> This is the behavior in Firefox (since version 38), Google Chrome (since
> 34), and Internet Explorer (since version 11).
> 
> If an author would like to prevent the autofilling of password fields in
> user management pages where a user can specify a new password for someone
> other than themself, autocomplete="new-password" should be specified, though
> support for this has not been implemented in all browsers yet.
> 
> *********
> 
> That's exactly the behavior you described in your access.redhat.com
> experiment above.  That behavior is fine. You, the user, told your browser
> to remember the password and the browser did your wishes.  And you found the
> page element said, autocomplete="off".

In a 'standard' form, that doesn't have login/password fields, setting autocomplete='off' means the browser doesn't remember the form content, period, ever. 

What the text here is saying is specifically that FF, Chrome, And Edge *ignore autocomplete='off'* - *even if you set it*, they will continue to ask if you want  login and password remembered.

> That's the audit requirement for the Satellite password field.  Behave the
> same way as that access.redhat.com password field. Don't depend on the
> browser default, specifically turn it off.  If the user tells the browser to
> remember the password, then the user made a choice and deals with the
> consequences.
> 
> That's all I'm asking.

Do this experiment:

* Start with a clean browser, make sure no passwords/logins are saved, make sure "Remember Logins" is turned off (I'm still in FF for this)
* Go to access.redhat.com, login in, log out, log in again
* Do the same for some Sat5 instance.

The behavior is identical, you won't be asked to save the password, there is no autofill on second login. Now, turn on "Remember Login"

* Go to access.redhat.com, login, say "No don't save" when the browser asks, logout, login again.
* Do the same on the Sat5 instance.

Again, the behavior is identical - you were asked, you said no, there is no autofill. Now, last time:

* access.redhat.com, login, say "Yes" to save, logout, log back in.
* Do the same on the Sat5 instance.

In both cases, the password field is autofilled.

In what scenario, are you seeing Sat5 remember and autofill the password, where access.redhat.com does not? Because I can't find such a case. And access.redhat.com has autocomplete='off'.

Thanks for wading through this.  The field behaves the same way no matter how it's set. I'll go back to the customer and see what they want to do.