Document security implications of shield and basic auth

The username/password stored by shield is not meant to be secure. If a site needs additional protection around the username/password, you should store them in the key module, which is an optional component for shield.

Sorry, but I believe you're fundamentally misunderstanding what Basic Auth, and by extension Shield, does and doesn't do.

First, Basic auth is, by definition, not secure. Just because it says 'username' and 'password' doesn't mean you should be linking it to anything you care about. If you are using basic auth to secure your Drupal site (IE serving sensitive data via anonymous pages and protecting it with basic auth), you're doing it wrong

Second, the main purpose of this module is to provide a basic gate against crawlers and the general public from 'stumbling' upon dev sites. Even with the key module, the password that is sent over the wire can easily be sniffed and should never be considered secure. If someone really wants into your dev site, shield likely won't protect you.

Third, if a site maintainer is exporting their website config to a public repo, they have more than shield keys to be worried about.

That all said, it might be useful to add a warning below the default 'provider' username/password fields to indicate that the username/password is stored in plain text... and to use the key module provider instead if you want other options (env variables, settings.php, etc) other than config.

But for all of the sites I've seen that use shield, the username/password is easily guessable and really only there to stop crawlers from indexing a dev site. It really shouldn't be used for anything else.

From the RFC:

Security of basic authentication
As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Note, while you could configure your server/site to always use SSL, I'd still recommend against it.

Thanks @japerry for taking the time to consider and write up the thorough reasoning.
Point 3 alone is enough to invalidate the IS reasoning.
That said, i agree that improving docs about this topic is a good thing.

We could add a salt, however I've onboarded quite a few clients who only knew their password through the config or a confluence page. Since it is almost always a shared password among a team, its already not secure. Heck, I'd argue the password on the config page itself should be changed to be a textfield instead of a password type, to make it very clear that its not supposed to be secure. So my preference would be to add documentation suggesting use of the key module when tighter security is desired, and the built-in functionality is primarily a basic stop to outsiders from casual access.

Yes, we should communicate in a way that does not raise too high security expectations.

Let's bikeshed a good text for the module page and readme here, and update it accordingly.