Larion Studios forum stores your passwords in unhashed plaintext. Don’t use a password there that you’ve used anywhere else.
That doesn’t really mean that they store it in plain text. They sent it to you after you finished creating your account, and it’s likely that the password was just in plain text during the registration. The question still remains whether they store their outgoing emails (in which case yes, your password would still be stored in plain text on their end, not in the database though).
Your guess is confirmed here.
There are plans to update the forum, including for better security (the main issue with changing the forum software is concern over reliably migrating all of the existing content). After emailing (admittedly not current best practice), the passwords are hashed and only the hash is stored.
…and later…
The forum has been updated to https, and passwords are no longer being sent by email.
Which raises the question of how old OP’s screen shot is.
Also, no, the password would not necessarily still be stored in plain text on their end. The cleartext password used in that email might be only in memory, and discarded after sending the message. Depends on how the UBB forum software implemented it and how Larian’s mail servers are set up.
EDIT: I just verified that this behavior has resurfaced since it was originally fixed. OP would do well to responsibly report it, rather than stirring up drama over a web forum account.
It is still a bad idea to send the password in plaintext via email. You never know when Bard will peek a look and then share your password along users as a demo account to try that forum.
There’s a lot of reasons why emailing passwords is not the best practice… But AI bots stealing your password to give people free demos is a wild paranoid fever dream.
EDIT: Apparently, I replied to a joke.
It is meant to be as a joke, of course the AI is not that dumb enough to give it away as free demo. Why am I being downvoted? Why don’t people understand jokes these days? Do I always have to include /s when making a sarcastic joke even though it is so obvious?
I’ve seen people argue stupider things earnestly.
Don’t use a password
therethat you’ve used anywhere elseJust get a password manager already
This is the correct answer.
While sending your password in plaintext over email is very much a bad idea and a very bad practice, it doesn’t mean they store your password in their database as plaintext.
Passwords shouldn’t be stored at all though 🤷♂️
That’s very unlikely. It’s running UBB Threads, which, from what I can tell, has an auth subsystem, which au minimum would do hashing. If it’s providing you with a default at sign-up, that’s different and is what appears to be a configurable setting.
If it is completely generated for you, here’s what probably happening:
- User creation module runs a password generator and stores this and the username in memory as string variables.
- User creation module calls back to storage module to store new user data in db, including the value of the generated password var.
- Either the storage module or another middleware module hashes the password while preparing to store.
- Storage module reports success to user creation.
- User creation module prints the vars to the welcome template and unloads them from memory.
TL;DR as this is running on a long-established commercial php forum package, with DB storage, it is incredibly unlikely that the password is stored in the DB as plaintext. At most it is likely stored in memory during creation. I cannot confirm, however, as it is not FOSS.
It sends the user generated password, not an auto generated one.
Yeah if they send the password in an email in plain text that’s not storing it. You can send the email before you store the password while it’s still in memory and then hash it and store it.
Stored in memory is still stored. It’s still unencrypted during data processing. Still bad practice and a security vulnerability at best. Email isn’t E2E encrypted.
Stored in memory is still stored.
Given what I know about how computers accept user input, I am fascinated to hear what the alternative is.
You have the text input feed directly into the encryption layer without an intermediary variable. The plaintext data should never be passable to an accessible variable which it must be to send the plaintext password in the email because it’s not an asynchronous process.
I’m surprised so many people are getting hung up on basic infosec.
Are you suggesting to do all this on the frontend before it goes to the backend?
The front end to backend traffic should be encrypted, hashing occurs on the backend. The backend should never have access to a variable with a plaintext password.
I’m going to have to stop replying because I don’t have the time to run every individual through infosec 101.
