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.
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.
Nobody suggested otherwise.
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.
It’s not a system generated one they sent, it was user generated.
OP would do well to responsibly report it, rather than stirring up drama over a web forum account.
¿Porque no los dos?
Took them 23 years to fix it last time, seems public awareness would be important in the interim, no?
Yes, still not worth risking using a duplicate password 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.
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.
I heard people’s LastPass accounts were getting compromised after that theft, but I also don’t know how strong their master passwords were.
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.
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.
Centralized, third party password managers, yes. Local-only managers like KeepassXC though, no concerns over some company getting hacked or cheeky
Applies to every site ever
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.
We all know that they store it in plain text.
Came here to say this
Well you’re late
I’m good thanks
Don’t use a password
therethat you’ve used anywhere elseJust 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.
BitWarden is awesome. Been using it since 2 of my colleagues went to work for them
How is this better than Firefox built-in password manager?
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.
So if my passwords are behind fingerprint there’s no problem?
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.
Thank you. I do use master password on everything. This does ease my mind a bit.
I just wanted to drop a reminder that both LastPass and Norton LifeLock have been hacked within the past year alone.
KeePass is a thing that exists and is fantastic.
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?
I don’t know what you’re trying to say. I think it was safe to assume Salty probably meant the local-based keepass or something like that?
I wouldn’t have immediately gone to text doc or spreadsheet. those aren’t password managers.
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.
I have mine in a self hosted Nextcloud instance, best of both worlds
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.
Use KeePassXC and you can’t get hacked
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.
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.
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.
One vote for 1Password here.
I literally trust them with my life. Agreed.
This is the correct answer.
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.
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
but then you expose your salt to the public
No, the client side hashing doesn’t substitutes anything server side, it just adds an extra step in the client
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
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?
If they can send you, your own password in plain text. That’s already bad enough. Just not good practise.
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.
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.
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.
What an absolutely shitty design.
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.
Isn’t this also what Windows NT used to do? I feel like I remember encountering this scenario
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]
Kind of.
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.
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.
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.
deleted by creator
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.
Looks like they address it here: https://forums.larian.com/ubbthreads.php?ubb=showflat&Number=669268#Post669268
it should be pretty straightforward to figure out whether they do or not
Not really since it’s closed-source: https://www.ubbcentral.com/
But they seem to have been in business since 1997, so I highly doubt that they’d fuck up the “never store passwords in plain text” rule.
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 thread is from 2020, where they said they fixed the password send issue.
Op, how old is ths image above?
Image was taken immediately before posting. The issue, apparently, has since shown up again.
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.
Encrypted passwords are still an unacceptable way to store passwords. They should be hashed.
(and salted before hashing.)
And marinated in butter milk.
Peppered if you’re feeling extra
Just because they send out the password does not mean it’s not hashed. They could send the email before hashing.
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.
deleted by creator
Would you accept “in a way that can be reversed”?
Passwords shouldn’t be stored at all though 🤷♂️
You mean plaintext passwords right? Ofcourse then need to store your (hashed)password!
The hash is not the password.
My bad! I just misunderstood >.<
If they stored the hashed password this thread wouldn’t exist.
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.
Set your password to an EICAR test string and see what else you can brick on their site.
Holy shit beautiful. Now I wanna try it everywhere
For those who haven’t made accounts yet, you don’t actually have to make an account to play Larian Studios games.
deleted by creator
what a stupid comment
Show me where the proof is that they STORE it plain text. This is just a screen of a mail after creating an account.
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.
That… is not how it works. It is usually hashed and at the same time an email is sent. Meaning it’s not stored plaintext in any storage.
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.
You’ll forgive me for not trusting anyone who can tell me my password that isn’t me.
That’s a totally different statement than that in your post.
Sure, if you’re illiterate.
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.So, it bad practice regardless.
Thankfully larian did address this, and fixed the issue as pointed out by another commenter.
Addressed here, with the follow up of fixing it:
https://forums.larian.com/ubbthreads.php?ubb=showflat&Number=669268#Post669268And that was back in 2020. 3 years ago.
they can send it without storing. In fact a lot of websites (mostly small outdated forum systems) send your password to your email before storing it.
It’s so sad that you spread misinformation based on your inadequate knowledge.
Lmao
deleted by creator
deleted by creator
