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.
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.
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.
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.
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”.
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.
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.
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.
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.
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 think you’re a liar
It’s a good thing your opinion makes no difference then isn’t it.
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.
25, I used to write proprietary networking protocols.
shit, I wonder why the protocol that’s much more well-adopted than yours does things differently
Imagining thinking what’s popular is best. Betamax, HD DVD, Firewire, Ogg Vorbis, Lemmy, and friends would all like a chat.
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.
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.
Yeah, but SSL/TLS also solves that problem in a standardized way.
In either case, the backend will have the plaintext password regardless of how it’s transmitted.
Yes, which is why they’re vulnerable to mitm and local sniffer attacks.
Have you found a mitm attack on TLS?
This guy’s a fucking clown, I’m sure he’s like 15
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”.
Oh yeah, this guy is a hoot.
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.
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.
Well it’s a good thing your opinion has no effect on reality.
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.
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.