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.
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.
Point is, a hash isn’t a password. giving the most you don’t need tech knowledge analogy, it’s like the passwords fingerprint.
The police station may keep your daughters fingerprint so that if they find a lost child they can recognize it is your daughter beyond any doubt. Your daughters fingerprints, is like a hash, your daughter is a password.
The police should not store your daughter… that’s bad practice. The fingerprints are all they should store, and needless to say the fingerprints aren’t your daughter, just as a hash isn’t a password.
It’s possible that this email is a result of forum user creation, so during that submission the plaintext password was available to send to the user. Then it would be hashed and stored.
I’m just explaining how user authentication works for most web applications. The server will process your plaintext password when your account is created. It should then store that as a hashed string, but it can ALSO send out an email with that plaintext password to the user describing their account creation. This post does not identify that passwords are stored in plaintext, it just identifies that they email plaintext passwords which is poor security practice.
You’re correct and after reading more of the thread I saw OP say this was sent immediately after registering. I don’t have reason to believe it is stirred in plaintext unless they’re storing s copy of every email they send.
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.
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.
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.
how long have you been a web developer? Because I’ve been doing it for six years and almost every web app I’ve ever seen uses http with TLS to send the plaintext password to the backend, where it’s popped into a request var at the controller level, then passed as an instance var to the service level, salted, hashed and stored. This includes apps that have to submit themselves for HIPAA compliance because they deal with PHI.
Maybe I’m misunderstanding you, but backend servers will almost always have the user-submitted password in plaintext as a variable, accessible to the backend server and any upstream proxies.
It’s even how it’s done in Lemmy. The bcrypt verify accepts the plaintext password and the expected salted hash.
I haven’t looked into it but I was wondering about the logistics of setting up a federated honeypot for server side stream sniffing to build a plaintext email/password database.
Not without compromised certificates they haven’t. You can tell because if they did they’d be world famous for having destroyed any and all internet security. Then again, they’d probably already be famous for having figured out a way to salt, hash and store passwords without ever holding them in memory first like they claim to do above, so maybe someone is lying on the internet about their vague “proprietary network protocols”.
Man, you sound like you’re just using random words you heard in class. Clearly you have no clue how user registration actually works, let alone backend development.
There are ways to have passwords transmitted completely encrypted, but it involves hitting the backend for a challenge, then using that challenge to encrypt the password client side before sending. It still gets decrypted on the backend tho before hash and store.
I asked because what you’re describing doesn’t do much if you understand how common web frameworks and runtime environments work.
The framework needs to parse the HTTP request. That means holding the parameters in a variable somewhere just to arrange them in a datastructure for processing.
But let’s ignore that and say we have some kind of system that stream parses the request right out of the buffer (which itself still needs to be held in memory for a bit, but let’s ignore that), and when it matches a preconfigured password parameter, passes it directly to the hashing system and nowhere else. I don’t think any framework in existence actually does this, but let’s run with it.
We’ll still need to pass that value by whatever the language uses for function passing. It will be in a variable at some point. Since we rarely write in C these days unless we have to, the variable doesn’t go away in the system until the garbage collection runs. Most systems don’t use ref counting (and I think it’s a mistake to disregard the simplicity of ref counting so universally, but that’s another discussion), so that could happen whenever the thread gets around to it.
But even if it runs in a timely fashion, the memory page now has to be released to the OS. Except most runtimes don’t. First, the variable in question almost certainly was not the only thing on that page. Second, runtimes rarely, if ever, release pages back to the OS. They figure if you’re using that much memory once, you’ll probably do it again. Why waste time releasing a page just to make you spend more time getting it again?
And we’re still not done. Let’s say we do release the page. The OS doesn’t zero it out. That old variable is still there, and it could be handed over to a completely different process. Due to Copy on Write, it won’t be cleared until that other process tries to write it. In other words, it could still be read by some random process on the system.
And we haven’t even mentioned what happens if we start swapping. IIRC, some Linux kernel versions in the 2.4 series decided to swap out to disk ahead of time, always having a copy of memory on disk. Even if you’re not running such an ancient version, you have to consider that the kernel could do as it pleases. Yeah, now that var potentially has a long lifespan.
To do what you want, we would need to coordinate clearing the var from the code down through the framework, runtime, and kernel. All to protect against a hypothetical memory attack. Which are actually quite difficult to pull off in practice. It’d be easier to attack the client’s machine in some way.
And on top of it, you’re running around with an undeserved sense of superiority while it’s clear you haven’t actually thought this through.
Yes. I agree 100% with the things I can and I defer to your experience where I can’t. I used to write proprietary networking protocols 20 years ago and that’s the knowledge and experience I’m leaning on.
As a matter of practice we would ensure to process passwords by encrypting the datasteam directly from the input, and they were never unencrypted in handling, so as to protect against various system and browser vulnerabilities. It would be a big deal to have them accessible in plaintext beyond the user client, not to mention accessible and processable by email generation methods and insecure email protocols.
I’m going to have to stop replying because I don’t have the time to run every individual through infosec 101.
Sorry, but you’re missing the point here. You cannot do anything with a password without storing it in memory. That’s not even infosec 101, that’s computing 101. Every computation is toggling bits between 1 and 0 and guess where these bits are stored? That’s right: in memory.
The backend should never have access to a variable with a plaintext password.
You know how the backend gets that password? In a plaintext variable. Because the server needs to decrypt the TLS data before doing any computations on it (and yes I know about homomorphic encryption, but no that wouldn’t work here).
Yes, I agree it’s terrible form to send out plain text passwords. And it would make me question their security practices as well. I agree that lots of people overreacted to your mistake, but this thread has proven that you’re not yet as knowledgeable as you claim to be.
You encrypt the datastream from the text input on the client side before storing it in a variable. It’s not rocket science. I did this shit 20 years ago. Letting a plaintext password leave the user client is fucking stupid.
there is no possible way to handle sensitive data without storing it in memory at some point
it’s where you do all the salting, hashing, and encrypting
emailing out credentials like this after sign up is certainly not best practice, but probably not a huge deal for a video game forum of all things. if you are re-using passwords then you already have a way bigger problem.
emailing out credentials like this after sign up is certainly not best practice,
Understatement of the year right here. Everyone in this thread is more interested in dunking on OP for the few wrong statements they make rather than focusing on the fact that a service is emailing their users their password (not an autogenerated “first time” one) in plaintext in an email.
there is no possible way to handle sensitive data without storing it in memory at some point
Since we’re nitpicking here - technically you can. They could run hashing client side first, and instead of sending the password in plain-text, you’d send a hashed version
This opens up the possibility of replay attacks in the case of data breaches, though, and those are much more common than http mitm attacks (made even less likely with the proliferation of https).
I’m not entirely sure whether hashing twice (local and server) is wise, having not thought through that entire threat vector. Generally I try to offload auth as much as I can to some sort of oauth provider, and hopefully they’ll all switch over to webauthn soon anyway.
I’m not really sure how it opens up replay attacks, since it doesn’t really change anything to the default auth. There are already sites that do this.
The only difference is that instead of sending an http request of { username = “MyUsername”, Password = “MyPassword” } changes to { username = “MyUsername”, Password = HashOf(“MyPassword”) } - and the HashOf(“MyPassword”) effectively becomes your password. - So I don’t know how that opens up a possibility for replay attack. There’s not really any difference between replaying a ClearText auth request vs an pre-hashed auth request. - Because everything else server side stays the same
(Not entirely auth related), but another approach of client side decryption is to handle decryption completely client site - meaning all your data is stored encrypted on the server, and the server sends you an encrypted container with your data that you decrypt client side. That’s how Proton(Mail) works in a nutshell
I’m not really sure how it opens up replay attacks
Put simply, jt allows an attacker with a leaked database to use the hashed password as a password. In your original comment, it seemed like you were suggesting hashing only before transmission, on the client; but hashing both before and after would indeed patch that particular vulnerability. I don’t know if there are potential problems with that strategy or not.
another approach of client side decryption is to handle decryption completely client site
Here’s potentially an opportunity for me to learn: how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? Since you can’t count on a web browser to have the private key, do you send down an encrypted private key that can only be decrypted with the user’s password? Is there some other way to do this that I’m not aware of?
In your original comment, it seemed like you were suggesting hashing only before transmission
Ok, that wasn’t what I was suggesting, no. That would effectively make your password hash the password itself - and it would kinda be stored in PlainText on the server, if you skip the client auth and send that value to the server directly through the api or something
how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? […] do you send down an encrypted private key that can only be decrypted with the user’s password?
Yes, pretty much. I can’t really find a good, detailed explanation from Proton how it exactly works, but LastPass uses the same zero-knowledge encryption approach - which they explained with some diagram here - with a good overview of the client/server separation of it’s hashing.
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’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
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.
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…)
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.
You can also tell if a site does this when they have seemingly arbitrary restrictions on passwords that are actually database text field restrictions.
Especially if they have a maximum password length. The maximum password length should be just the maximum length the server will accept, because it should be hashed to a constant length before going into the database.
I recently created an Activision account during a free weekend event and discovered their password system is completely broken. 30 character limit but refused to accept any more than 12 characters. Kept erroring out with must be less than 30. Once I got it down to 12 it accepted that, but then it complained about certain special characters. Definitely not giving them financial information.
My bank has a character limit, but they don’t tell you about it; they just trim the password you’ve set before hashing + saving it, then when you go to login if you don’t trim your password the same way they did, login fails.
I only know this because the mobile app will actually grey out the login button as soon as you enter more than the character limit. The web app just leaves you to be confused.
I had a similar situation with my health insurance company, except I think they added the character limit a while after I had set my password T_T. So, it worked for months, then they changed the mobile app so I couldn’t enter a long password… And then eventually they changed the website too and then I couldn’t log in at all. Thaaaaanks.
Doesnt lemmy also do it? I think I ve heard from Ruben at Boostforlemmy that lemmy only treats first 60 characters of your password as a password and the rest gets discarded. [citation needed]
Can’t say I’ve ever tried to use a password quite that long, so I’m not sure.
Not ideal, but trimming it (especially when you’re keeping 60 chars) isn’t the end of the world. It was just super confusing that the web app doesn’t trim it during login as well. There’s no indication that your password was modified or what you’ve entered to login is too long. Just ‘incorrect user/pass’ despite entering what you’ve just set. That char limit for my bank is only 16 chars, so it’s easy to hit.
It’s a big deal IMO, particularly because at login it doesn’t do the same. From the user perspective, your password has effectively been modified without your knowledge and no reasonable way of finding out. Good luck getting access to your account.
When a bank does this it should be considered gross negligence.
The official web UI doesn’t let you enter more than 60 characters, but doesn’t indicate that at all. So you can keep typing past 60 characters but it won’t get added to the input field and you can’t really see that. If you paste a password into the field, it gets trimmed to 60 characters.
When creating a password, the server checks that it isn’t longer than 60 characters and returns an error if so. On login, however, it silently trims the password to 72 bytes, because that’s what the hashing algorithm they use supports.
My bank if you get your card number through the app has a dynamic ccv that changes every day so while not perfect is what I use whenever purchasing online
Especially if they have a maximum password length.
Not really, there are good reasons to limit password length. Like not wanting to waste compute time hashing huge passwords sent by a malicious actor. Or using bcrypt for your hashes, which has a 72 byte input limit and was considered the best option not that long ago. The limit just has to be reasonable; 72 lowercase letters is more entropy then the bcrypt hash you get out of it, for example.
Yes, reasonable limits are fine, I was talking more like 12 or 13 characters max. That’s probably indicative of a database field limit, and I’ve seen that a fair amount because my password manager defaults to 14 characters.
It’s 2023, I really hope people are not using the same password in multiple places. Password managers solved this problem a decade ago. Use one, with multi factor auth on important sites like email.
I’ve used the same password for everything since 1991. If anyone’s cracked it, they haven’t attempted to get into my shit. Probably because there’s nothing worthwhile to steal.
First of all they wouldn’t know there’s nothing worthwhile until they got in. But most importantly if you’re using the same password for everything since 91 there’s around a 0% chance that password hasn’t been leaked. This means that a random person can have access to everything that you have that’s not 2fa protected without you even noticing. You said that no one tried to get into your things, how would you know? Most places don’t let you know when someone login successfully, and a lot of other places do so with an email which the attacker can quickly delete.
If you really use the same password for everything since a long while back anyone who knows your email address can get into anything yours, getting a hold of one of those password dumps is really easy, especially older ones.
if you’re using the same password for everything since 91 there’s around a 0% chance that password hasn’t been leaked
Plot twist, they’ve never had their password leaked due to never having a password.
They spend every last waking moment trolling through public or university libraries to find computers that people haven’t logged out of, and are still logged into social media, dialup modems, irc, bbs, mainframes, etc. It’s these accounts they make posts from.
Pretty lonely world when you only ever get to make one comment on one account at max like once a week. And then you never get to check the replies. You never get to check your email either, you don’t know if anyone has sent you and e-card for your birthday.
Oh and not to speak of constantly getting kicked out of those libraries once the librarians recognize you. To the point where you have to move to yet another city to have any online time again.
But hey, they’ve never had their password leak at least!
First of all they wouldn’t know there’s nothing worthwhile until they got in.
I mean, you can read all my comments and posts publicly, and social media accounts and such are just about the only thing I’ve ever had passwords for. 🤷🏻♂️
You finna steal my Lemmy account?
Security is only important when you give a shit about what can be taken without it.
Yeah some sites also dont have passwords, they just send a login link to your email every time.
I prefer passwords so I don’t have to go to my email to log in, but I understand it’s easier for some people to do it that way. Your email address becomes your identity then.
Oh, they are. I keep telling people to WRITE DOWN YOUR PASSWORDS, and NEVER use same password on two sites. They dont listen. Its a lot easier to just remember 1-4 variations of a password and use that than carry around a password notebook. And they think themselves safe.
I’m thinking most people shouldnt use passwords at all anymore. They are a huge point of failure because people are people. We need something else to be the norm. How can we make hardware keys or something the norm for logging in? Have everyone carry around a bankcard-like thing that fit into every computer where people need credentials. Would’nt that be safer while still being accessible and convenient?
There are yubikeys you can use to login, but it requires installing stuff on each computer you want to access. Nothing is simpler then passwords. :)
I used a yubikey for a while, they are alright, but I could only use it for logging on to a computer, not for logging into specific sites. Even though I guess that could be solved with a password manager integration.
Nothing is simpler than passwords. But we want something thats both simple and safe. Even for lazy people, tech-unsawy people, and people with bad memory.
What if every pc came with a jubikey-ish reader and every website supported a browser api for it? Probably not jubikey, but something that fit in a wallet like bank cards do (but also was an open tech so that anyone can implement and sell cards). Wouldn’t it be both safer and simpler than passwords? It would take some time to turn around of course but the same was probably the case for https, 2fa, ipv6, and tpm’s.
Those are called smart cards. Traditional smart cards needed centralized management of credentials, but FIDO2 smart cards exist that work like the keys. The reason tokens are more typically USB-based (or NFC) is every PC has USB, but most don’t have smart card readers.
FIDO2 can be used for passwordless log in on a few sites, but the site and browser need to support the feature (no extra installation). It sets a pin on the yubikey and when entered the key does all the authentication. It will likely be seen more as Apple “passkeys” gain more popularity, Windows and Android already have native support but don’t market as hard.
so your lemmy password would be ilovemypasswordLEMMY
and your reddit password would be ilovemypasswordREDDIT
that way they can keep their shitty password but it won’t be the same password on every site and they have an easy way to remember what the proper password is for the site they want to accesss
Still better than using the same password. My argument is if you can only convince them to do at least that, it’s better than every site using the same password
That’s horrible if you ever become the victim of a targeted attack. Compromise your password once on some random shitty site and they’ve got access to everything.
It’s also quite likely that incidents involving password dumps will have crackers filtering the dumped data looking for exactly passwords like this.
Oh, they are. I keep telling people to WRITE DOWN YOUR PASSWORDS, and NEVER use same password on two sites. They dont listen. Its a lot easier to just remember 1-4 variations of a password and use that than carry around a password notebook. And they think themselves safe.
Honestly, the best solution for this is a password manager and not a notebook. The average person is not going to come up with strong passwords on their own for every website. A password manager once setup can be more convenient than whatever they were doing before, so if you can get people to use one they’ll be in much better shape.
I’m thinking most people shouldnt use passwords at all anymore. They are a huge point of failure because people are people. We need something else to be the norm. How can we make hardware keys or something the norm for logging in? Have everyone carry around a bankcard-like thing that fit into every computer where people need credentials. Would’nt that be safer while still being accessible and convenient?
My understanding is that this is basically what the whole passkeys initiative is. I have sort of mixed feelings on it. Hardware tokens for logging in is great, but I worry about people stealing the hardware tokens from others. Mostly people are going to use their phones, though, which should have some other mechanism of authentication.
They can’t send it if they haven’t stored it, that’s the proof. Whether temporary or not it’s a weakness and attack vector for obtaining unhashed passwords. And if they stored it, it should be immediately hashed at which point they can’t send it.
They can still send it while the value is in memory.
But it’s unlikely that emails are sent synchronously. At which point, it has to be added to a job queue somewhere which might not be in memory.
There is also the communication with that job queue, and logging along the way, and any email logging.
Email isn’t secure, either.
Plenty of website did this… more than a decade ago, and even then plenty of security conscious people writing blogs and posting on social media begging devs to stop doing this.
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?
The only annoying part about the modern world is that you want to have that keepass file synchronized between devices, at which point you either go down the path of something like Synchthing (not mainstream user friendly) or you just end up asking yourself “fine, what cloud service do I trust to not go looking at my files?”
I always synced my database manually either directly over usb, or wifi (KDE Connect). I have to admit that it’s not really user friendly, but once I got used to it, it’s no problem at all.
And uploading it to any cloud service should be fine as long as it’s encrypted with a strong password. But that kind of defeats the point of an offline password-manager in my opinion.
Good advice only for tech-savvy and people who are interested in self-hosting. There’s so many things that can go wrong like improper backups and accidental networking problems.
Well, you can. But you have to be PERSONALLY hacked. At which point you’re at a level of risk equal to “will my house burn and my notebook full of passwords get lost?”
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
I use Pleasant Password Manager, which is keepass compatible. Big fan of offline cache with online sync for access anywhere with an internet connection on top of my phone offline
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.
This is true, but they have your encrypted vault, and all the technical data to make unlimited informed attempts at cracking it. If you used LastPass, you definitely need to be changing passwords for your critical services at a minimum.
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.
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.
On mobile I’m assuming. I personally don’t know a way to bypass the fingerprint locks. And if you’re also having Firefox create random difficult passwords, its significantly better than reusing the same one. So you’re probably a much harder target than the majority of people. I’d have to double check but I think even on desktop if you have a master password for Firefox and don’t just have logins auto filled you’re probably good there too.
Sending your password right after you created it might not be best practice, but it doesn’t mean it’s stored unhashed in the database. It looks like they’re using a third party forum software, so it should be pretty straightforward to figure out whether they do or not.
Yeah, I was looking it up, and when I saw they’ve been selling this forum software since 1997 I was less confident about passwords being hashed. They address it in their forums and they’re making it clear that the passwords are actually hashed, and they’re looking at migrating to other solutions regardless.
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).
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.
Personally the risk of bitwarden is outweighed by its convenience (compared to self hosted/local only solutions) in my opinion, but I know that’ll change real quick if bitwarden ever has a breach. If it does I’m jumping ship to a self hosted or local only solution, but I’m hoping that doesn’t have to happen
Bitwarden is end to end encrypted. If the host gets hacked your passwords are still as safe as your master password is. Self hosting wouldn’t really be a huge help there. Possibly even detrimental depending on your level of competence at securing a public facing web host.
Yeah at this point it’s considered likely that LastPass vaults are being cracked, based on LP being the common link between various other accounts that are being breeched.
A small number of rounds of encryption being the default for users with old enough accounts is believed to be a significant part of the issue. It means even if their password was a good one, the vault can be brute forced comparatively quickly.
If their password was actually good (18+ random characters) it’s not feasible with current day technology to brute force, no matter how few PBKDF2 iterations were used.
Obviously it’s still a big issue because in many cases people don’t use strong enough passwords (and apparently LastPass stored some of the information in plaintext) but a strong password is still good protection provided the encryption algorithm doesn’t have any known exploitable weaknesses.
your passwords are still as safe as your master password is
They’re as safe as your master password is…and as the encryption is. LastPass famously got hacked recently, and in the aftermath of that many users noticed that their vault was encrypted using very small numbers of rounds of PBKDF2. The recommended number of rounds had increased, but LastPass left the number actually used too low for some users, rather than automatically increasing it. Users of Bitwarden and any other password vault should ensure that their vault is using the strongest encryption available.
Self hosting wouldn’t really be a huge help there
Well, self-hosting makes you a smaller target. The most determined attackers are likely going to go after the biggest target, which is going to be a centralised service with thousands of users’ vaults. If you host it yourself they probably won’t even know it exists, so unless there’s reason for someone to be specifically targeting you (e.g. you’re a public figure), or you get hacked by some broad untargeted attack, you might be better off self-hosted from a purely security standpoint.
(That said, I still use centrally-hosted Bitwarden. The convenience is worth it to me.)
You’re underestimating the attack surface of a self hosted set up. You don’t need to be specifically targeted if, for instance, someone hacks the Bitwarden docker image you’re using, or slips a malicious link into a tutorial you’re reading. It’s not a set it and forget it solution either, you’re responsible for updating it, and the host OS. Like I said, depending on your competency, it’s not inherently more secure.
This is why I don’t use a common centralized password manager, just like I don’t use any of the most popular remote desktop solutions like TeamViewer for unattended access.
I run a consumer copy of Pleasant Password Manager out of AWS and use NoMachine for unattended access to any machines where I need it.
Security through obscurity is tried and true. Put as little of your security attack surface in the hands of others as is reasonable.
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.
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.
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.
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.
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?
Add comment