The exec team isn’t changing. They didn’t even mention the scummy anticompetitive (and potentially illegal in some jurisdictions) fee vouchers they were handing out to try to steal users from AppLovin, nor was the sneaky update of their license terms that was done to enable the whole snafu addressed.
I don’t think Unity is coming back from this. The industry doesn’t trust them anymore, and nothing has been done to materially address the root cause of that lack of trust: the exec team and the board.
If they do a leadership shakeup, it’s possible they can save it. But I don’t think that’s going to happen.
While they didn’t directly address the retroactive license changes, they did counter the argument. The following text being relevant.
The Runtime Fee policy will only apply beginning with the next LTS version of Unity shipping in 2024 and beyond. Your games that are currently shipped and the projects you are currently working on will not be included – unless you choose to upgrade them to this new version of Unity.
We will make sure that you can stay on the terms applicable for the version of Unity editor you are using – as long as you keep using that version.
I don’t really care if or how Unity reacts to the accusations. The fact remains that they did it, and their response is trying to deflect attention from the fact that they did do it.
I thought at minimum they needed a sacrificial lamb. The screw up was too big and their first response too blithering.
I was watching a YouTube video of one game Dev saying he's met John (CEO) and said he's quite pleasant and has a great rapport with staff. However, this move shows a complete and utter lack of competence.
It’s just that everyone who’s actually responsible for the decision is on the exec team, and it seems pretty clear that neither they nor the board have any plans to go anywhere. And if they try to crucify some middle management type who was just trying to do their job… well, that’s gonna be a fucking HUGE wrongful termination lawsuit, perhaps with some slander complaints thrown in.
This whole thing is a masterclass in machine gunning one’s own foot.
They’ve proven they can’t be trusted. The people who devised and attempted to enact this plan - the exec team - have not gone anywhere, and they aren’t going to. They have shown the industry who they are, and they clearly don’t give a shit about business ethics or even legality (the AppLovin shit smells an awful fucking lot like anticompetitive market interference). They will definitely try something similar in the future.
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).
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.
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?
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.
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.
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.
I'd start with Bioshock. It's definitely worth playing, but probably a bit dated feeling now. I really like HZD, it's excellent, but God of War is by far my favorite. Combat is incredible, story is an awesome "not revisionist history" of mythology, and Chris Judge as Kratos is just 👌
Damn. I loved horizon, but gow... Now you're making me want to play it again and all you had to do was show me the box. I have like 1,000 hours and ten playthroughs of horizon 1 too. Aaaa I'm trying to finish cyberpunk
The only thing shocking about this graph to me is how few copies were purchased on GOG. I guess I'm in the minority of people who prefer to support their store directly as competition to Steam .
Honestly disappointed with the combination of batch awards and probably the shortest acceptance speech timer I've seen. This game awards felt solely for producers and publishers, not for the people who actually made these games. I get not wanting another 8 min speech, but it left a bad taste in my mouth
Games
Oldest
This magazine is not receiving updates (last activity 0 day(s) ago).