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’ve never even heard of the game studio I’m not defending them, I was replying to the person who said the company should never have your unhashed password, and explaining that they have to at some point in the process
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…)
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.
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.
…and if they keep the emails they send out archived (which would be reasonable), they also have it stored in plaintext there.
Automatically generated emails usually don’t get saved.
As the designated email dev at my company I can confidently say this is not true.
Not saying that this specific email is persisted, but almost all that I work with are. It’s a very common practice.
Yeah, we save most emails sent out at my work.
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.
But that still means they had your plaintext password at some point.
Edit: which, as some replies suggest, may not actually be much of an issue.
I’m still skeptical about them returning it, however.
hashing on client side is considered a bad idea and almost never done.
you actually send your password “in plain text” every time you sign up.
Really everytime you log in too.
It’s not a bad idea and it is often done, just not in a browser/webapp context.
deleted by creator
Can you give an example where this is done?
Sorry, I should have included an example in my comment to clarify, but I was in a rush.
HMAC is a widely used technique relies on hashing of a shared secret for verifying authenticity and integrity of a message, for example.
Of course. You receive the password in plain on account creation, do the process you need, and then store it hashed.
That’s fine and normal
deleted by creator
When you create an account you type your password in. This gets sent to the server, and then it is hashed and stored
So there is a period of time where they have your unhashed password
This is true of every website you have ever made a password on
deleted by creator
I’ve never even heard of the game studio I’m not defending them, I was replying to the person who said the company should never have your unhashed password, and explaining that they have to at some point in the process
So why would an agent at Larian have man-in-the-middle access between the password being sent to the server, and the auto-hash?
Um. Yeah, because you provided it to them. They have to have it in plain text in order to hash it.
this is still a terrible idea. the system should never know the plaintext password.
logs capture a lot even automated emails. i don’t see a single reason to send the user their plaintext password and many reasons why they shouldn’t
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…)
I’ve literally never had a service provider email me my own password ever. Maybe a OTP, but never my actual password. And especially not in plaintext.
What would be the necessity behind emailing someone their own password? Doesn’t that defeat the purpose of having a password? Email isn’t secure.
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.
They’re probably just young.
Idk if I’m misremembering, but it’s my impression that they did this a lot in the 2000s, haha. I guess bad practices have a habit of sticking around
I’ve had service providers physically mail my own password to me before. Just crazy.
Always use unique passwords for every site.
So it’s in plaintext in their email system
Generated emails usually don’t get saved, as soon as it is delivered it will be gone.
these emails don’t usually get copied to local outbox folder (as any oher auto generated emails)
password may end up in cache somewhere tho…
and this is why it’s a bad idea and rarely done nowadays
“Kinda a bad idea?” This is fucking insane.
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.