New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Does anyone know wtf this guy is snorting? I don't know if he even knows wtf he's arguing about, he's not making any sense.
This isn't true, most modern developed applications keep data encrypted in both disk and RAM at all times. The only time a deencryption happens is on the fly by whatever the front end layer is and usually only for visualization.
For example, keeping this as simple as best I can, your login here would be stored as a token in the database and stored as a token in your browser. When you login the web service immediately converts it to a token which is communicated to the backend as a token. Both devices, in device RAM, will only store and compare tokens (as the data holding the password is actually usually stored only on the network card's internal RAM and validated against the NICs internal CPU). This is why you need something like wireshark to listen to the network card, and why you can't just filter network packets in raw RAM. Keep in mind those packets should also be encrypted (https). Interestingly perhaps, part of the reason packets are stored on a network card, is to help prevent a DDOS due to the impact of early DDOS attacks (which could at the time cause RAM to overload or a CPU to be overworked).
You would need to break best practices intentionally to make this happen otherwise. This applies to desktop, mobile and web applications specifically to ensure information is not stored in long or temporary storage unencrypted. You would actually need to intentionally develop practices not included in things like bcrypt to force this to happen.
Anyway, there are exceptions of course (and some small temporary opportunities to still exploit this data). But just wanted to make sure this was clarified.
It's been my experience the more 'absolute' someone speaks, the less experience they have. As the more you know the more variations you see and the less absolute a point of view or statement becomes (see Dunning–Kruger effect).
They should be called "Bargain Whores" then!
Also, where's this? Asking for a friend.
You're talking out of your a-hole. There's NO application designed like that. Name one.
Indians are cheap to hire but not that cheap.
Slack. Telegram. Anything built on chromium. Anything built on .NET. anything built in C++.
Your turn.
No. That doesn't even pass a basic sanity check. The data needs to be unencrypted for the app to access it and operate on it, it's up to the kernel to allow/prevent access and hardware to prevent going around the kernel.
No. That's not how any of this works. There's protocols for doing something along those lines, and it's a specific standard. I recall finding it last time looked into wireguard encryption between two servers. MACSEC
No. Look up OSI layers.
For what to happen? Break best practices by decrypting data to work on it? That doesn't make sense.
Nothing was clarified, there's several glaring errors in your understanding of various things. You should refrain from further security discussions.
To be clear, I'm talking about application encrypted data (i.e. passwords) not basic application data. Big difference.
Yes it is, sorry you couldn't find something on Google
As I said, keeping it simple to explain on LET. Don't really care if you agree - I've proven you wrong enough times to write a novel on neckbeards
Data is only decrepyted when necessary at the application layer and dropped. If you store encrypted data unencrypted - you should not be writing software. Please don't.
Nope. I am sorry you are misinformed. Maybe it's a good time to go back to school and see how software has changed over the last 20 years
Still waiting? What desktop and web applications are storing your password in RAM unencrypted?
I've checked Microsoft Office - PW stored encrypted in RAM.
I've checked Steam - PW stored encrypted in RAM.
I've checked Windows logins - PW stored encrypted in RAM (actually wiped right after, but windows credentials is a thing)
I've checked Adobe - PW stored encrypted in RAM.
Seriously, back up your statement here.
What is the saying, that doesn't make enough sense to even be wrong?
Oh boy. You're so wrong on all your points, it's not worth my time. Maybe someone else will chime in and educate you without you being an asshole.
It's funny you mention Dunning-Kruger, as you're the dumb guy thinking you know more than you do, not the smart guy not realizing he's actually smarter than he thinks.
Are you about to go off on how Canadians only use the term Work Order again, and that a VPN provider also selling Proxys would be an absolute moron?
Software changed since you retired. What was safe a decade ago is gone - do us all a favour and avoid security topics on this matter. People like you caused heartbleed.
Reading this, and your prior comment, made me feel insulted over all the wrong facts in there. Oh my god.
It really doesn't work like that. Unless you somehow have internal knowledge/access to some software (AND HARDWARE) we don't know about, a lot of applications don't work like that, much less the ones you used as an example. That's not how it works and you're heavily misinformed, and all what you're doing right now is spread misinformation believing you're 100% right.
Keep digging a hole, you look pretty amateur after your previous posts. You still don't know wtf the OSI layer is... It's one thing to not know something, it's way worse to think something so wrong is right.
People like you don't understand Heartbleed (or else you'd know how wrong your posts are), so that's ironic for you to say.
Actually, I do want to come back, and say fuck you. People like you storing passwords in RAM unnecessarily unencrypted because you are lazy and it is easy, is the reason there was so much shit software a decade ago. It is lazy developers like you, that think storing unencrypted user access data is OK that has opened up a ridiculous amount of exploits - all because you were too lazy to run a bcrypt check on a login. On behalf of anyone who lost a password they didn't need to, I just wanted to make sure that message was loudly delivered to someone like you
"Stored".. " in RAM" isn't a thing because RAM isn't persistent. It's stored encrypted on persistent storage and decrypted in RAM to be used. There's no point having it encrypted in RAM, you can't do anything with it.
You need to speak with more defined locations and usage than what you're suggesting.
@KermEd V. @TimboJones
@stevewatson301 @adly
Care to take over? The natives are tired of me.
Welcome to a world were stored can mean temporary, and where memory allocations for variables (unless you garbage collect them) remain active until the application is closed. Storing someone's password in RAM (i.e. assigning a variable and not releasing it with their password unencrypted) instead of a token or a hash is not acceptable as a security practice in 2022. It just is. I don't know who let you write software, but just lets stop that as soon as we can
Oh come on, me and Tim are just doing the IT equivalent of having a few beers.
You two need to get a room
I'm just joking, I like the banter between you two. It's like an old married couple (think Frank and Marie in Everybody Loves Raymond)
You're misinformed and don't understand how decryption works.
These exploits aren't from careless programmers leaving keys in RAM when not in use, the point of the exploits are to get the keys when in memory/use. They never ever should have ever had that access to begin with, hence, an exploit.
It's VERY clear you don't write software. I have to say, you've got big balls acting like you know shit when you have no education or work experience in the subject. I can only guess you have the job you have now from bullshitting and blaming others when you're wrong.
SMH
I think it is because deep down he knows I'm sometimes right and it scares him
After “encrypting” this data in RAM, how exactly is it decrypted without placing the decryption key also in RAM and thus defeating the entire purpose?
The only time you're right is when you didn't take a left. There's nothing you got right in this thread or any previous argument we've had.
I'll bite because I consider this a fun topic but...
I'll also be the first to say, I don't really care to be accurate on LET and I am fully willing to rush a detail, skip specifics, or even make an absolute statement (that is anything but an absolute statement) just to drive a point. There are reasons, sometimes laziness, sometimes it just doesn't matter to me for the purpose of the argument to go into more detail on how it works. For example, I'm not going into how approved packets are passed from the NIC card, and stored into RAM, with the OS forwarding it where it needs to go. And I'm certainly not about to break that down into more detail, nor care if people like that explanation or not. It doesn't really matter for the purpose of the argument and who cares that much about a LET post anyway. So, I'm going to approximate some statements to be brief - I don't care if the summarization is off.
In this case, I really only care about one statement:
The problem is, this base statement is incorrect. Many times over.
Remember, in order for this statement to be true, everything in memory must be unencrypted. And well, it just isn't.
Lets exclude obviously unencrypted data and low value data that can't remain encrypted at runtime (such as viewing an encrypted PNG, which would need to be unencrypted to use a standard PNG viewer).
First, we all know RAM itself can be encrypted, to prevent cold boot attacks and any data source can be encrypted with the keys stored somewhere. So in of itself, this statement is false before we even begin defending it. But the fact is, modern processes for encrypted data has changed in such a way that even without encrypting the RAM, it is untrue. And before people say this is all that difficult, it was one of the protection methods of the Xbox 360.
Second, there are a few specific examples of active encryption going on. For example, large applications with large data sets that unencrypt only as needed (cloud drives for example). And proprietary formats that remain encrypted in RAM and are decrypted at run-time by the CPU without needing to return to RAM in a raw unencrypted format.
Finally, however, what I'm really focusing on is a super common use case. Specifically, high-value critical data like passwords. If you've worked with anything web driven these days, you've probably worked with something like jwt tokens (as just one example). I used this earlier thinking folks would know what I'm talking about but if you've worked with web tokens you already know what I'm about to say. You don't store unencrypted passwords... because there is no reason to decrypt it in the first place. All matching and comparisons is done entirely on encrypted outputs, the password is never known to the system - and you don't need it to. Therefore, if you use a website, you ARE storing encrypted passwords in your memory every single day. 99% of which are never submitted as passwords.
Now, again, that isn't to say there aren't moments of exploitation in this area. We know sign-up keyloggers, older apps storing input text in raw consecutive strings (modern browsers especially avoid this now adays, which is why I hinted at Chromium apps), and you could even pick at my statement about NIC cards temporarily unencrypting the HTTPS/SSL packet, and sending it to the OS and eventually app, which would go into RAM unencrypted and would sit in garbage collection for a few cycles (I'd estimate ~4 to 6ms on most systems). Or that the password once received does need an initial encryption before begin compared to the backend encrypted value (I think I mentioned bcrypt earlier), which if the developer submitted as raw strings (happens more than it should) would mean the web service also has an exposed reference for 2 to 3ms in RAM until garbage collection happens. However, we all know that it is also bad practice to submit passwords to applications or web services everytime - we should be submitting tokens until they expire (which could be days, weeks or months) meaning that this whole exchange only happens 1 to 2% of the time. And that even when we submit that data, we can do a partial encryption CPU bound, so even then it doesn't need to sit in RAM at any point unencrypted (although warranted few developers do this, again because they be lazy). Regardless, however, the point is about never having encrypted data in RAM. And if you used any website in the last decade you are storing encrypted password information both on your hard-drive and in your RAM at any given moment.
So, three times in a row, we've shown that data can be (and is) stored encrypted on the hard drive and in memory. And all we need to do is look at a single website to see this in action.
endrant. Call me crazy if you will on the topic
dafuq goin on
That's only true when you are running your code in SGX enclave.
@KermEd is either a schizo or some 13 y.o. kid fresh off HackForums.
encrypted PNG viewer
NIC-approved packets
too lazy to run a bcrypt check on a login
It's best practice nowadays to pass your encryption key as a command line argument, that way nobody feels left out.
its really humbling to read a shitload of argument that i cannot possibly comprehend.
This is starting to feel like one of those TV shows where an interviewer asks a few kids to explain a topic that the kids can't realistically know anything about.