Larion Studios forum stores your passwords in unhashed plaintext. Don’t use a password there that you’ve used anywhere else.
Hello, c/Games mod here.
This post has been reviewed as valid by the mod team
For everyone infosec culture, hashing and salting password consist in using one-way mathematical functions to encrypt passwords. It is a very commonly used security practice to make it more difficult for an attacker that was able to steal a database to obtain the password. As the website is unable to decrypt said password (thank to the one way mathematical function), the only way to send you back your password in this manner is to have it unhashed and unsalted in his database.
But
In the current case, this is a registration email, which may have been sent before the initial hashing and salting. In this case we cannot say for sure if Larion Studios indeed have unhashed and unsalted password in his database.
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.
You should always change your password from the system generated one to prevent that from happening. The app that you signed up for should enforce that by making you change your password when you log in.
I actually think this is the case. I could be completely wrong but I swear I saw the same question like 6 years ago in another forum software that looks exactly like this one lol. And people compalined about it storing plain text, but the response when asking the forum people was that it was only during that password creation, it’s not actually stored.
I don’t know if it’s crazy for me to think it’s the same forum from that many years ago, still doing the same thing and getting the same question.
Honestly, why risk duplicate passwords even then? I have one strong password that I use for accessing my password manager, and let the password manager generate unique random passwords. Even if I had an easier password that I duplicated with some small changes, I’d still use a password manager to autofill it anyway. I use bitwarden personally, you can also self host it with vaultwarden but it seemed like more trouble than it was worth imo
This is a friendly reminder to everyone that password managers are not risk free either. LastPass was hacked last year, NortonLifeLock earlier this year.
Don’t use a password
therethat you’ve used anywhere else
Just get a password manager already
I want to suggest 1Password even though it’s not free (I used bitwarden for many years though). It has its own SSH agent which is a dream.
The only problem with their SSH agent is, if you store let’s say 6 keys and the server is set to accept a maximum of 5 keys before booting you, and the correct key happens to be key number 6, you can end up being IP banned.
This happened to me on my own server :P
That being said, my experience was using the very first GA release of their SSH Agent, so it’s possible the problem has been sorted by now.
Firefox is extremely easy to get your password from behind the *** if it autofills. Requires physical access, but literally takes seconds. Right click the field, inspect and change the field type from password to text.
I just wanted to drop a reminder that both LastPass and Norton LifeLock have been hacked within the past year alone.
I just want to drop a reminder (to you specifically) that you don’t have to use a cloud-based password manager. Roll your own.
Can I discourage rolling your own password manager (like using a text doc or spreadsheet) and instead recommend what you hopefully meant, self-hosting your own password manager?
And here’s a reminder that trusting centralized service with high security access control is usually a bad idea.
I stay away from LastPass for the same reasons I stay away from TeamViewer. Security through obscurity on top of decoupling my security interests from others means other people being attacked is much less likely to cause me harm at the same time
Offline password managers like KeepassXC are a thing, plus self hosted remote storage like Nextcloud means you’re not worried about any third party interference
And at least for LastPass no passwords were compromised. Saying they “were hacked” and leaving the extent of the hack out implies something worse IMO, it’s misleading. The safes themselves are E2E encrypted so they also don’t have your password.
That said, my vote is to Bitwarden as it’s open source and allows self hosting if you think you’re a more reliable admin than they are. Open plus more choice is always better.
And at least for LastPass no passwords were compromised
I’m just going to leave this here:
https://krebsonsecurity.com/2023/09/experts-fear-crooks-are-cracking-keys-stolen-in-lastpass-breach/
Just this month a link was made between $35 million in crypto being stolen and the 150 victims being LastPass users.
In 2022 Lastpass was compromised through a developer’s laptop and had customer data like emails, names, addresses, partial credit cards, website urls, and most importantly vaults stolen last year, and given they’re closed source, have no independent audits, and don’t release white papers, we have no idea how good their encryption schemes actually are nor if they have any obvious vulnerabilities.
In 2021, users were warned their master passwords were compromised.
In 2020 they had an issue with the browser extension not using the Windows Data Protection API and just saving the master password to a local file.
What will 2024 bring for LastPass? They were hacked, and there’s no reason to think they won’t see more breaches of confidential customer information and even passwords in the future. This is a repeated pattern, and I’d better trust a post-it-note on my monitor for security than LastPass at this point.
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.
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.
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.
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.
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.
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.
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
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.
It’s not a bad idea and it is often done, just not in a browser/webapp context.
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
