no, they probably dont.
they just send it to your email upon registration, which is kinda a bad idea, but they are probably storing passwords hashed afterwards.
I wonder how much this varies depending on the amount of data it would require to store the emails of a company. I know nothing about this subject, but does it occur where companies with very large email lists would forgo storing those types of emails to save data costs?
In my experience it varies a lot. Even in our own system certain emails are stored differently. There are a few "we legally have to deliver this email and might need to prove it later" notifications. We store a PDF of those in s3. For others we might just save the data, a sent timestamp, and a key for which email visual template was used.
I also thought of a counter argument to my point overnight. We don't store one super duper high volume email which is the email that only has an MFA code. We would also absolutely never ever dream about allowing a plaintext password in an email, so we're probably following different patterns in the first place.
I find that very hard to believe. While it is less common nowadays, many, if not most, mailing list and forum software sent passwords in plaintext in emails.
A lot of cottage industry web apps also did the same.
Is it though? While it certainly isn't something I'd recommend, and I've encountered it before, if E2E encryption exists we cannot assume a data exposure had occurred.
What they do on the backend has nothing to do with this notification system. Think of it as one of these credentialess authentication systems that send a 'magic link' to your inbox.
passwords are usually hashed server-side tho and that's done for a reason.
if handling passwords correctly, server side hashing is way more secure then client-side. (with client side hashing, hash becomes the password...)