Bug 1060777

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

 We don't set it on login pages, as that would disable password managers.

Re-opening this RFE because it needs to be revisited.  The current behavior is not a best security practice and is triggering customer audit failures because of the potential ugly scenario below.

Alice launches a browser and logs into Satellite.  The fields in the login form are *not* set to explicitly disable autocomplete, and Alice behaves like 99+ percent of the population and does not turn off autocomplete in her browser.

Alice logs into Satellite, performs her tasks, closes her browser, and finishes her shift for the day.

Later that night, Bob launches a browser from the same workstation.  Bob is mad at Alice and Bob wants to make everyone think Alice sabotaged the company.

Bob logs into Satellite as Alice.  He starts typing Alice's name in the username field. He types "A" and the fields in the login form conveniently populate - including the password field with Alice's password.

Bob impersonates Alice inside Satellite and wreaks havoc across the company.

This RFE was closed with WontFix because of password managers. The reasoning seems to be, the password is inside a password manager and the browser automatically fills it in, so the Satellite Admin doesn't need to know it.  

We need to revisit that decision.

I propose the following behavior as a bug fix for both Satellite 5 and 6:

Change the default behavior for all password fields to turn autocomplete off.  In cases where customers need autocomplete on, customers can override the default behavior by telling their browsers to remember the password.

For the RFE portion - for browsers with no ability to remember passwords, provide a Satellite configuration option enable autocomplete with password fields from the Satellite side.  Put in lots of text for why this is not a good idea and a confirmation for people who want to choose it.

I'm pasting in a request from the customer on this.  They're running Satellite 5.7.

**********

@Greg Scott — Is there any way to edit the source code of that login form (at least temporarily) while we wait on an RFE? I have tried locating where that login form is generated, but was unable to find it easily. It seems some portions of the web pages for Satellite are generated from Perl, other parts with Python, etc. It’s definitely not static HTML — at least, not anywhere I could find.

All that I need to do to remediate this is change this:
<form name="loginForm" id="loginForm" […]>

To this:
<form name="loginForm" id="loginForm" autocomplete="off" […]>

***********

Can we do anything to help them out? It will help get past a security audit.

And a question.  Having autocomplete in password fields really is a bug and not a feature.  The RFE portion is to provide an option to allow it - which might not even be a good idea.

Should I file a bug for Satellite 5 and another one for Satellite 6 to turn off autocomplete in password fields?  Or is it OK to leave the issue here?

thanks

- Greg

Satellite 5 and 6 are tracked separately within bugzilla; therefore, 2 bugzillas would be appropriate.

OK.  I did 2 more bugzillas.  

Satellite 6 at https://bugzilla.redhat.com/show_bug.cgi?id=1468759
Satellite 5 at https://bugzilla.redhat.com/show_bug.cgi?id=1468754