Privacy Please
Tune into "Privacy Please," where hosts Cam and Gabe engage with privacy and security professionals around the planet. They bring expert insights to the table and break down complicated tech stuff everyone can understand.
Privacy Please
S6, E245 - Hard-coded Secrets and Unencrypted Data: A Digital Security Nightmare
Several popular Chrome extensions, including privacy and security tools, have been found leaking sensitive data through unencrypted HTTP and hard-coded credentials in their code. Security is both hard and easy - hard because of existing unencrypted protocols and trust placed in developers, but easy because fundamental security practices should be common knowledge in 2025.
• Chrome extensions including DualSafe Password Manager and Avast Online Security are leaking sensitive user data
• HTTP vs HTTPS - the 'S' stands for security and encrypts data transmission over the internet
• HTTPS Only extension from EFF forces secure connections when browsing
• Hard-coded credentials in extensions create permanent security vulnerabilities
• Developers sometimes collect excessive data "just in case" rather than minimizing collection
• OWASP (Open Web Application Security Project) provides essential resources for developers
• Technology abstraction makes users less aware of security fundamentals
• The newly restarted OWASP Nomad chapter offers virtual community for application security
Check out our GitHub repository of privacy resources at "Awesome Privacy Engineering Tools" for more information on implementing better privacy practices in development.
All righty then. Ladies and gentlemen, welcome back to another episode of Privacy, please. Cameron Ivey, here with Gabe Gumbs, we're just hanging out, we're chatting, we're chatting, we've been chatting, catching up a bit. How are you doing? I'm good man, always good, always good to connect, love, chatting with you, and there's a lot going on, but we pinpointed a specific story that seemed pretty interesting kind of take us back to our beginning days.
Speaker 2:Um, yeah, we talk a lot offline about a ton of security and a ton of privacy, and you know that intersection of security and privacy is what privacy, please, is all about always has been since day one, and, and we came across, uh, we came across an article about, uh, you know, some chrome extensions leaking information because it was using HTTP over HTTPS, and we're having an interesting conversation that we figured was worthy of having online as well too. Refresh me in the details, sure.
Speaker 1:Yeah, yeah, so just for just to kind of high level. So several popular Chrome extensions, including some marketed as privacy and security tools stuff like DualSafe, password Manager and Avast Online Security and Privacy found to be leaking sensitive data. So the vulnerabilities came from two main issues transmitting sensitive data, browser domains, machine IDs, os details, etc.
Speaker 2:It was unencrypted http and using hard-coded credentials, api keys, secrets, tokens so many things in that sentence yeah, so break that down there's a lot of naughty things in that sentence a lot yeah, that's a lot um hard-coded keys bad sending data over the internet not encrypted bad embedded in the extension of job javascripts, which is pretty common yeah, bad, and you know the internet well.
Speaker 2:Why do we need security and privacy? Well, we need them fundamentally, as humans, to feel safe, to fulfill one of those, those basic needs of ours. Right, security is a very basic human need and that doesn't change in our digital world. Yeah, but the internet wasn't designed with security in mind initially not for the most part, right, the? What we know is the commercial internet grew out of something that wasn't intended to be accessed by everyone all the time in any open manner, and the world also has changed now that it's all interconnected. And so, you know, http as a protocol is not encrypted by default. Https is the S and HTTP is for security. We're probably telling things to much of our audience that that knows, but you know if you don't. You now know the distinction between those two things.
Speaker 2:And all the way back to our very first episode, we were talking about another extension. So over five years ago, we were talking about another extension that we were advising our listeners to use, and it enforces HTTPS. It's called HTTPS Only. It's developed by Freedom Foundation I think it's EFFFF, if I'm not mistaken. I think they're the ones that published the HTTPS only plugin. If it's not somebody you're allowed to at me on this one For this you can at me, go ahead and at me and correct me, but what it does is if you try to visit, say, www, transcend that. Let me stop, sorry. Http colon slash, slash, transcendio. It will automatically send you over to HTTPS, right, and it won't let you go to HTTP. Even if Transcend for some reason had an HTTP endpoint, it will not let you go there. It will force you over to the other one, because we shouldn't be transmitting anything over the internet in clear text any longer with HTTP. We should stop doing that. Period.
Speaker 2:The protocol still exists and arguably it exists for some good reasons. But it exists because it has and it is out there and it is widely embedded into many things. But anyone developing any security or privacy plugin it belies logic that anything at all could even communicate on a standard port 80 HTTP port. It just shouldn't. Https by default communicates over port 443, ssl, and so it's an interesting article, largely because it's a firm reminder that security is both hard and easy in some ways right. It's hard to get right because there are all of these existing things like unencrypted protocols that are still out in the wild and the trust we put into developers and random plugins. But it's easy also because it's like really dude, like HTTP. Really we're hard coding secrets. It's 2025, gee, what's that Can we not do that?
Speaker 1:Let me paint a scenario, gabe. So when they're mentioning, even trusted extensions can become attack vectors. So what does it mean by that? What are some of the common mistakes that you see, or you've seen or you know about where developers can neglect proper security practices? I mean, that's the human Humans.
Speaker 2:Humans are humans. But before I pick on the devs too much, because I spent a lot of years in application security and building application security products and being an application security pen tester, so I spent a lot of years beating up developers in security, so I feel I owe it to them at this point to be very, very nice to them. There are a few places where these things get slippery, though. Right Like I can publish my own Chrome plugin and I can make it look very similar and close to yours so that I trick people in a downloading mind. That's a huge problem.
Speaker 2:That's a significant problem, and so that's problem number one I think a lot of people should be on the lookout for is are you getting that plugin, even from the official source? Is that the official place? Is that the right one? Humans being humans, things like hard-coded keys probably a byproduct of development testing In order to make that process quicker use temporary, unsafe keys that you reuse in development because it shortens the workflow that you need to do. But then a lot of times that kind of thing gets committed further upstream or downstream is the case, maybe in your product pipeline and find its way into production, and that's not good. And so you know communities like OWASP, the Open Web Application Security shit. What does the P stand for? I don't remember Open Web Application Security something, but it's a nonprofit group that promotes web application securities, right? So like they publish a top 10 of things that you should be mindful of, and so my short answer to you is don't listen to what I have to say about that.
Speaker 2:I turn to the OWASP community for web application developers. Like they have a ton of resources on what they should do, how they should do it. There are no shortage of resources. There's also a lot of resources already built into programming frameworks that will automatically implement different security protocols, so you know. So as a developer, you don't have to remember doing those things. So hopefully that's advice to young, burgeoning developers that are not intimately familiar.
Speaker 2:If you're not familiar with OWASP, go check them out. There's also a new OWASP Nomad chapter, so most OWASP chapters are kind of in person. There's a new global one, or Restud. We rebooted we I didn't reboot it. Jerry Hoff has been a longstanding member of the OWASP community Great dude, One of the most amazing AppSec folks I know. He restarted the Nomad chapter. So if you want to join a virtual chapter of the open web app Clay's Security, because there's one near you, go check out Jerry Hoff. You can find him probably on LinkedIn, some of the socials. Go check out OWASP. Go check out the OWASP Nomad group and there's a ton of resources there for you developers. We love you, Love you. We wouldn't have a lot of this without you, Both the good and the bad.
Speaker 1:What do you think about like? Do you think that there should be a deeper discussion around like regulatory pressure, around increased for extension marketplaces to enforce, like more development?
Speaker 2:standards. I don't know if more regulation is gonna gonna help like. This is just. We've got so much regulation our heads already dizzy. Right, like you're already not supposed to transmit. You know, like medical records and clear text, right?
Speaker 2:A lot of that the problem, I think, with that type of regulation that we're now discussing is it's very consumer-oriented. Those that have listened to the show in the past know that I weirdly do like regulation in a lot of ways, like very it's. It's very antithetical to my personality to actually like regulation, but but I but I do enjoy the guardrails that that at least helps define, like, hey, everyone, here's what you should do, right, like. The problem is when they're just guidelines. People don't just follow the guidelines. Problem is when they're regulation. People just check the box sometimes, right, but I don't think regulation helps there. I don't think it would. It certainly could be done. We have consumer protections, we have multiple consumer protection agencies, in fact, in the US, but I don't see how you solve that problem with that.
Speaker 1:Well, like you just said, though, it's funny because you think of http and some people are like whatever yeah but maybe that's part of the reason, because it's being overlooked, because people are just not really thinking that it's the more abstracted people get from technology too, right, like, think of the generations below us at this point.
Speaker 2:Right, I am not certain how many of them can tell you the difference between http and hp. Like I don't actually know the answer, but I know that technology is so abstracted away that most of them have never, like, had to sign their own cert or work with a cert authority. Right, like, because they probably didn't intimately interact with technology as a youngster. Like not in that meaningful way. They don't have to think about am I going to a secure site or not, because most sites on the internet default to actps. Now that most people don't even think about it, right, like, they may have learned that. Oh, I should look to see if the little lock is there. Maybe they've learned that, but maybe they haven't. Yeah, you know, maybe they've learned that when it says, oh, this certificate is entrusted, continue anyway. No, maybe you don't continue like, maybe they have. Maybe, like, whatever internet era, keep going. Yeah, yeah, abstraction of technology from humans in general definitely creates more space for this kind of thing.
Speaker 1:Do you think that privacy tools could actually be a helpful thing for the security teams? When it comes to something like this, yeah, what's the first thing that kind of sticks out to you that could benefit?
Speaker 2:I think it has to start with some education, right, like it has to start with some understanding of what we've spent a lot of time, just like I talked about OWASP. Owasp is all about security and so as a by-product, there's a lot of privacy built into the practices that are preached there. But I know of no just privacy-focused efforts around application security development. We published some resources around this. We've got a little GitHub with all those privacy resources. We can drop the link again here With. You know, with all those privacy resources, we can drop the link again here. It's awesome, awesome privacy guy Privacy. Awesome privacy engineering tools. Awesome privacy engineering tools. That's the name of it. Yeah, it's on GitHub. You'll find it under that name or under my name on Cape Gums, you'll see it there, and so we've published some things around those. But it starts with definitely some education. I think those developers need to before we blame them for leaking things like did they really understand that they shouldn't have been doing?
Speaker 2:that I would hope so and I would have expected, like I absolutely would have expected that. But do we know that? Has someone told them that? Has that communication occurred? I don't know.
Speaker 1:You know, this makes me think too, and I don't know if I'm too far out in left field, but I think there's the term like lack of visibility. I think that's why it's so important to have a good privacy tool in place that also integrates well with your security tools. So, first of all, companies are still doing this. They're collecting way too much data that they don't even need, so that hurts your lack of visibility, because you don't even know what you got, why you got it.
Speaker 1:Exactly so. If someone does get in, it'd be nice that. That's why having a good privacy tool that integrates with-. No, you're right.
Speaker 2:These browser extensions are sending back a lot of sensitive data that you just right here. I like OS is like all kinds of things, which I'm certain I know why the tools send those things back. But now you're collecting information about the users of your products, like, did you need all of it, right? I can tell you that, as a developer, sometimes there's uh, not myself, but you know developers will, sometimes they will they will sometimes capture more than needed because it's easier to throw things out than it is to go back and go get it right. It's like ah, let me just grab all of the data and then I'll just sift out what I need.
Speaker 1:Do you also do that as a developer? Do you also do that as like for testing too?
Speaker 2:Sometimes absolutely.
Speaker 1:Yeah, yeah, absolutely.
Speaker 2:Makes sense. Telemetry, just general understanding of what's happening at the other end, yeah, but sometimes that's not really, it's not always needed. Can you achieve the same goal right, Like can you whatever problem you were trying to solve for development? Can you solve that problem without getting more data?
Speaker 1:That requires a lot more work, Gabe.
Speaker 2:And I'll tell you data being what it is, everyone is in, the more data is better than less game these days and AI is when they made that problem worse. Right, like more data, because we have to train on that data. We want more data, more, more data, more data we want more data, more more data, more data.
Speaker 1:Yeah, I agree with you. I think this topic is actually. You can go pretty far with this. Obviously, we could talk you guys into the ground, but We'll post some resources.
Speaker 2:Let's post some OWASP resources. We'll post the awesome privacy engineering resources. Um, I know you guys over at transcend have some great resources on this stuff too. Um, we've got a couple of things also because myota actually, you know, we we create a, an infrastructure product that application developers actually do use. So, like some of our, some of our customers like, when their application takes data in it, it goes inside of a secure MyOta vault and that's where it operates out of. It's actually it's part of their application infrastructure. So we'll post some resources on this topic. It's a lot of good reading on this. Love it.
Speaker 1:Yeah, all right. Well, thank you guys. Thanks, gabe. All right, I'll see you guys in the next one. Till next time.
