To a first order of approximation, no service that uses password-based authentication treats your password as a secret. If you’ve used the web for several years and accrued the typically uncountable number of user accounts across myriad websites, then I can confidently estimate that half of those websites store your password without encryption, such that anyone who helps run that service can read it at will, and can share it freely.

And from there, they’ll do all sorts of awful things with it! They’ll attach it to intracompany emails, and they’ll include it in dumps of user analytics to services they in turn use. Automated scripts will make back-up copies of the database holding your user record, password and all, sending it to other computers across the internet.

These services don’t do this because they hate you, or because they want to steal from you. It’s because so much software powering the web is terrible, written rapidly and under duress for employers who don’t care about how it works, so long as it works on the surface. These services cut corners by avoiding the one-time investment to implement basic data encryption, and today they throw your password around in broad daylight because, from their perspective, it helps them get their job done faster. It helps them serve you better, right?

We all regularly hear that nobody knows how to manage their passwords properly. Less often do I hear the complementary truth that nobody who runs online services knows how to store and protect their users’ passwords. As one in a privileged position to see how the sausage gets made, my stance is this: Every time you enter a password into a service that you personally do not have complete control over, you have lost control of that password, permanently. You must assume that this password is now known to everyone who runs the service you submitted the password to, and also to every other service that this service contracts with in turn. Should any one of these parties, at any level, slip up and expose your password-and-identity pairing to a crafty malefactor, that’s that.

I have this attitude because, in my day-job role as a freelance software consultant, I will from time to time answer a call to survey an ancient but active codebase powering some long-running and lucrative project. While doing so, I find one particular design horror so often that I check for it first, and I see it present more often than I don’t: full user credentials, including passwords, stored as unencrypted plain text in a database table (or a plain text file, in those cases where the last programmer didn’t know about proper databases).

Even though finding this design flaw no longer surprises me, I still wince every time I encounter it. It feels nonconsensual to suddenly find myself exposed to a cache of real people’s active passwords, each tied to an email address and therefore a personal identity. I’d feel the same discovering medical records lying around, perhaps, if each such record were entirely readable in a fraction of a second. In the time it takes me to realize what I’m seeing, I have learned secrets I didn’t want to know.

As you can imagine, I make it a priority project to improve this situation as soon as possible, overhauling the system to work exclusively with encrypted passwords instead. Hardly the only one in this business, I know that many other consultants take similar tacks with their own clients. And I have to assume that all our combined efforts must surely amount to a single pebble on the vast beach of web services running just fine, their owners not cognizant of any reason to care a whit why or how their user authentication methods work, much less hire anyone to improve them.

If you have the means, use a password-manager program, such as 1Password or LastPass, that helps you generate a different, long, and random password for every online service you create an account for. Through this method, even when your password on one service gets compromised, it affects your identity only on that service — not your identity across the entire internet, and thus across your whole life.

Browsers have begun supporting this strategy, too, without the need for purchasing additional software. I myself have lately started using Safari’s built-in ability to generate and paste in crazy-long, site-specific passwords (even though they prove troublesome to look up and key in when I need to subsequently log into a service through a native iOS app).

If you keep to the old ways of applying a small handful of memorized passwords across all your accounts, then I hope you can find another way to limit the damage when you find that one of them, lying among loose drifts on more computers than you could ever guess, has some day turned against you.