'Standard practice'. And yet there are plenty of shops that will either symmetrically encrypt passwords (at best, the email address or username is used as an I

'Standard practice'. And yet there are plenty of shops that will either symmetrically encrypt passwords (at best, the email address or username is used as an IV), Log passwords stupidly [0], have a piss-poor integration where "Oh we have base64 encode the actual XML payload in the soap service and tag it '<Encrypted>`, ship it!" [1], or are just plain too budget strapped to replace the 'forgot password' functionality that told a user their password vs forcing a reset. And I think that last point hits it well. i.e. at least a plurality of those horrors were done before standard practices evolved to the current state, but nobody can get the budget/time to fix it. (And, I will say, having 'fixed' more than one of the above cases, it definitely has a user impact which can lead to the folks approving the work having an uncomfortable conversation with customers. B: "We forced a password reset to update security standards" C: "Wait so your security standards were subpar!!!" [2] [0] - Example; logging invalid attempts, but wait a user only failed because they did TypoEmailAddress@gmailcom instead of TypoEmailAddress@gmail.com. [1] - Yes. This was a thing I got to deal with once. What's even more annoying is that it was a SOAP service so of course the pattern eliminated most of the potential usefulness of a SOAP service. [2] - That said, usually the person making this complaint, is the person who historically was e-mailing their account rep to give them their password, vs using the 'correct flow but bad implementation' password reset we had in place as a stopgap.