We are all prostitutes in some way, shape or form under capitalism. Tell them that at thanksgiving and example that renting yourself to a company to drive trucks, scan tills,deliver pizza is not that different to renting yourself out for sex. Both involve you doing a service for others in exchange for cash.
You’d think that a country with a recent, well documented, lived example of how prohibition doesn’t actually fix anything might have learnt something from the experience
I’m not saying that we shouldn’t prohibit people from doing antisocial things that harm others, I’m saying that adults doing things/consuming things/selling things in a safe, regulated way where everyone consents, understands what they are doing and the risks associated and no one gets hurt probably shouldn’t be illegal.
“We’re making the clock app cloud enabled! Now you’ll be able to set and clear alarms from any of your Windows™ connected devices! We’ve also implemented customisable actions with PowerShell scripting now fully integrated! Want your display to show a lovely sunrise every morning? Clock App can do it!”
Next minute -
“Security update 13112023-33: A malicious user can access the internet-exposed ClockAccess™ interface on your devices, setting alarms with scripted actions that can cause complete loss or exfiltration of your data.
To mitigate this issue, we have shifted ClockAccess™ to a more secure, fully cloud-based service. This also means that once updated, the application will be unavailable if there is no internet access. Please adjust your usage of the application accordingly.
As the Clock app runs under a Local Administrator account on consumer versions of Windows™ and Domain Administrator on Windows Server™ machines, this is a high priority update and it will be installed on application startup without user confirmation. You may notice increased resource utilisation by the Clock App, this is a necessary increase due to new and improved security features. It is recommended that at least one vCPU and 1.5GB of memory be made available at all times for efficient operation of the app.”
I do not respect you and would not care or even notice if you disappeared tomorrow and no one ever found you because you had been kidnapped and murdered in the worst way imaginable.
True~ish. Farmers get subsidies in general, not just ranchers. But this is also Hamburger we are talking about. If the meatless patties were to replace the steak in a steak sandwich, they’d be more comparable in “price for function” comparison. The meat in hamburger patties is recovery from more expensive cuts and is basically designed to be cheap while the meatless patties are specifically designed to replace them.
It’s like building a small fence with pallet wood vs. what you’d buy at a lowes or something. Neither is gonna be priced at the premium of a boutique lumber mill or restaurant, but their inception doesn’t startvevenly.
one day to recoup from no sleep and working nonstop everyday. One day to do all the chores and errands you didn’t have time for during the work week. Then time to finally… do it all over again yay!
The very fact you're able to do all of this is an effect of politics. And there are people that also would like to have similar rights to exist the way the feel is right for them, but they can't.
The very fact that they’re able to do all of this is also an effect of the mitochondria in their cells. But if people tell me to stop talking about mitochondria 24/7, then I should just find a group of other mitochondria enthusiasts to interact with instead of ranting about how I’m ““right”” to make everything about mitochondria.
Freedom of association = (meeting with friends) that’s definitely political
Barbecue = relatively safe to use and won’t explode because of government regulation, politics.
Jalapeño poppers = safe to eat due to food safety standards, again politics.
Conversation with friends = regulated by societal norms and acceptable behaviours, an output of the political environment - ‘let’s not talk about Trump or abortion to keep it “civil”’
Games/books/puzzle = function of the economy regulated by the government and laws. Consumer protections etc etc
I know you’re trying to be dismissive and funny but yeah…you’re just proving the 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.
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 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.
I’ve been cutting every piece of software that shows me ads out of my life. I basically just have Lemmy and streaming services now. It’s pretty great, but now if I’m somewhere and I see or hear an ad I get extremely annoyed.
The lemmy post about them feeling gross was relatable. Like everyone’s so fake enjoying [product] and you’re just watching asking "how does this convince anyone to buy [product]
Doesn’t everyone feel this way about ads? I don’t feel like the advert algorithms ever get a good lock on me. On the few occasions I’ve gotten adverts it has been for things like “Visit the UAE” or “Visit Dubai” and a lot of pregnancy and feminine hygiene related stuff.
I’m a gay man. Pretty sure I’d get stoned to death in Dubai/UAE, and pregnancy is just not on the menu for me.
Yup, they never figured me out either.. Ads are annoying and stupid and thinking about how much resources are poured into them and how much everyone's time is wasted makes me angry.
I don't remember the last time I ever saw an ad but I'm pretty sure if I got one it would be completely unrelated as well. I got way too many different personas on the interwebs. I don't even know anymore which one is real.
This is me with those stupid “Dude relaaaaaaaxxxx” ads for Hello Fresh. I watch them, oddly mesmerized by how bad they are. Also some of the things they show are literally 3 ingredients (potatoes, cheese, pepper for smashed potatoes).
To their credit, they’ve stopped claiming they’re cheaper than groceries
I have it, unfortunately it does not seem to block Snapchat ads. Or maybe it does and I just haven’t noticed? A lot of the time I’m using Snapchat out of the house, I haven’t bothered to set up an exit note for tail scale yet (Even worse, tell scale is still broken for me on Android)
Yeah, I’ve noticed it’s gotten really bad. I’m not a sports fan myself, but I’ve tried watching NFL with my brother, and it’s borderline unwatchable due to the sheer amount of ads.
lemmy.world
Top