181–190 of 265 posts
Hostnames are not private information. There are too many ways how they get leaked to the outside world. It can be useful to hide a private service behind a URL that isn't easy to guess (less attack surfaces, because a lot of attackers can't find the service). But it needs to be inside the URL path, not the hostname. bad: my-hidden-fileservice-007-abc123.example.com/ good: fileservice.example.com/my-hidden-service-00…
Marginally better for sure but in this case the path would also have been "leaked" to the sentry instance owned by developers of the the NAS device phoning home. This can happen in zillions of ways and is a good reason to use relatively opaque urls in generally and not "friendly ids" and generally being careful abou putting secrets in URLs.
Earlier quoted context omitted.
Hehe, just reading that. > The poster described how she was able to retrieve her car after service just by giving the attendant her last name. Now any normal car owner would be happy about how easy it was to get her car back, but someone with a security mindset immediately thinks: “Can I really get a car just by knowing the last name of someone whose car is being serviced?” Just a couple of hours ago, I picked my car…
I feel like that car security situation also is sort of setup to tell us about how folks with a security mindset can go overboard? Some car dealership who never had a car stolen hires a consultant and they identify this pickup situation as a problem. Then they implement some wild security and now customers who just dropped off their car, just talked to the same customer service person about the weather ... have to go…
I can imagine being in info-sec is a rough life. When you get breached, they're blamed. So they spend all their time red-teaming and coming up with outlandish ways that their systems can be compromised, and equally outlandish hoops for users to jump through just to use their product. So the product gets all these hoops. And then an attacker gets even more creative, breaches you again, and now your product has horrible UX + you're still getting breached.
Earlier quoted context omitted.
I feel like that car security situation also is sort of setup to tell us about how folks with a security mindset can go overboard? Some car dealership who never had a car stolen hires a consultant and they identify this pickup situation as a problem. Then they implement some wild security and now customers who just dropped off their car, just talked to the same customer service person about the weather ... have to go…
And then some person realizes that government ids can be faked, so they set up a system of doing a retinal scan of the person dropping off the car and then comparing it to the retinal scan of the person picking it up. Then they realize that one person may be bribed so they require at least two people to verify at pickup and drop off. Meanwhile, a car has never ever been stolen this way.
Definitely over the top issue.
Earlier quoted context omitted.
Obligatory Bruce Scneier: https://www.schneier.com/blog/archives/2008/03/the_security_...
Hehe, just reading that. > The poster described how she was able to retrieve her car after service just by giving the attendant her last name. Now any normal car owner would be happy about how easy it was to get her car back, but someone with a security mindset immediately thinks: “Can I really get a car just by knowing the last name of someone whose car is being serviced?” Just a couple of hours ago, I picked my car…
It's risky, sure. But the garage situation also seems risky.
Stuff like this is why I consider uBlock Origin to be the bare minimum security software for going on the web. The amount of 3rd party scripts running on most pages, constantly leaking data to everybody listening, is just mind boggling. It's treating a symptom rather than a disease, but what else can we do?
Earlier quoted context omitted.
> the idea being that the platform is "someone else's computer" I have a vague memory of once having a userscript or browser extension that replaced every instance of the word "cloud" with "other peoples' computers". (iirc while funny, it was not practical, and I removed it). fwiw I agree and I do not believe using "the cloud" for everything is a good idea either, I've just never heard of the word "clown" being used…
“Cloud to butt” was popular in the early cloud days. It went around Google internally, and caused some… interesting issues.
Earlier quoted context omitted.
I feel like that car security situation also is sort of setup to tell us about how folks with a security mindset can go overboard? Some car dealership who never had a car stolen hires a consultant and they identify this pickup situation as a problem. Then they implement some wild security and now customers who just dropped off their car, just talked to the same customer service person about the weather ... have to go…
It certainly feels that way here in 2026. It seems like I'm spending so much time "verifying" and "authenticating" and clicking somewhere so that the service can send me a code in E-mail. And more and more services are getting super aggressive. Biometrics, 2FA, uploading government ID, uploading face scans... Good grief! I can imagine being in info-sec is a rough life. When you get breached, they're blamed. So they s…
I mean, I don't mind if the same dev public-keys are used nearly everywhere in internal dev and testing environments... but JFC, don't deploy them to client infrastructure for our apps.
FWIW, aside... for about the last decade, I generally separate auth from the application I'm working with, relying on a limited set of established roles and RSA signed JWTs, allowing for the configuration of one or more issuers. This allows for a "devauth" that you can run locally for a whoever you want usage. While more easily integrating into other SSO systems and bridges with other auth services/systems in differing production environments. Even with firm SSO/Ouath, etc services, it's still the gist of configuration.