Kibana: Watcher UI and redacted passwords

[inqueue]

Kibana version: 6.3.1
Elasticsearch version: 6.3.1

As of Elasticsearch 6.3.0, watches that contain passwords for authentication such as HTTP input with basic credentials, are returned by the Watcher API with passwords redacted. For example:

"auth": {
          "basic": {
            "username": "elastic",
            "password": "::es_redacted::"
          }
        }

If the Watcher API receives a simulate request having "password": "::es_redacted::" in the payload, Elasticsearch responds with:

{"statusCode":400,"error":"Bad Request","message":"[parse_exception] found redacted password in field [password]"}

And Kibana displays a big red warning banner about the situation.

Is there any way to make the user experience better? Maybe existing watches could be executed by ID instead of relying on the payload. Watches in edit mode would still require entering a valid password as it is required for saving the watch anyway.

Watches with HTTP input credentials worked prior to 6.3

This behavior is coming from a change made for Elasticsearch 6.3.0 where passwords coming back from the Watcher API are redacted. The added security is great. However, this appears to be broken to users coming from versions prior to 6.3.0 as the UI did not work like this previously. Is it a breaking change?

@spinscale

[inqueue]

Appears to be a dup of https://github.com/elastic/kibana/issues/18309.

[remd]

Is this still an issue or can this be closed?

[alisonelizabeth]

@remd this is still valid.

[zeleznypa]

Still relevant issue :(

[JSkier21]

Also experienced this on 7.5.1.

Update:

Wouldn't it make sense to use the keystore for this since authentication has occurred? I have to put in the password each time I make a change or want to simulate a rule; this isn't ideal.

I understand the security implications of why this happened in the first place, but the inconvenience factor should hold some weight on this issue as well.