Rendered at 19:44:52 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dumberquestions 3 hours ago [-]
Friend of mine, who's been treated as the unlucky one as an inside joke, made a binance account - after avoiding crypto for years - just hours before the hack happened, it's now official lore that this whole chain of security incidents is entirely his fault.
gdulli 42 minutes ago [-]
Due to similar bad timing I got my first Playstation right before the hack in the early 2010s that took down the Playstation network for a whole month. When they offered a make-good to their customers I didn't qualify because my account was too new. I never bought another Sony product again.
trio8453 3 hours ago [-]
Kind of insane how much of the front page is about security compromises today.
coldpie 3 hours ago [-]
For 50 years, computer security has largely been built on the theory that most targets aren't worth the relatively high effort to compromise, so it's not worth it to spend the money on security. We're now reaching a point where the effort to compromise is dropping close to 0, which means we've got 50 years of insecure software to reckon for.
The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
yrjrjjrjjtjjr 1 minutes ago [-]
> The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised.
This is completely unrealistic advice that 0% of people follow.
pdpi 2 hours ago [-]
A better framing is that security has largely been built on theory that most targets aren't worth the effort to target, so security spending is focused on preventing/mitigating untargeted spray-and-pray attacks.
Veserv 2 hours ago [-]
Computer security has largely been built on the “not enough bears” theory.
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
bongofizzbuzz 2 hours ago [-]
Lotka-Volterra predator prey dynamics will emerge.
Terr_ 2 hours ago [-]
> Sure, the bears are breeding
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
My new security through obscurity is to collect esoteric modern LLM written software, like this sweet gem of a terminal editor written in fortran: https://shithub.sh/fortrangoingonforty/facsimile
specproc 1 hours ago [-]
> what would happen if Iran got complete control of this system?
What would happen if America got complete control of this system?
Oh wait. Oops.
n_u 3 hours ago [-]
I think we are about to enter a world where security compromises occur at least an order of magnitude more often due to AI. The fact that AI is sometimes wrong benefits the attacker because they can just automate attacking with agents until they breach a system and the failed attempts don't matter.
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
swatcoder 3 hours ago [-]
The corollary is that service access will become increasingly penalized, authenticated, and finicky as the most general first line defense against automated "informed brute force" attackers will be to slow or ban access that looks like them.
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
himata4113 3 hours ago [-]
This is just the beginning, once kimi k3.1 is out with cyber curated dataset post training we will likely see far more advanced attacks.
SRI only really works if the 3rd-party script never changes, in which case why is it a third-party script?
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
skinfaxi 33 minutes ago [-]
Letting any vendor arbitrarily update code running on your customer's computers without even your knowledge is insane.
himata4113 2 hours ago [-]
usually scripts have versions, this protects you from compromised cdns as well where you publish assets in a different location compared to where your frontend is served.
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
chistev 2 hours ago [-]
At least people aren't going to complain today that it's all AI related submissions.
HolyLampshade 2 hours ago [-]
Hey now, that's for tomorrow when someone writes an article about LLM contribution to these security events.
ciupicri 2 hours ago [-]
Well, it's called Hacker News after all :-)
mcmcmc 3 hours ago [-]
P(doom) on the rise
rhodey 59 minutes ago [-]
This is the same style of attack that took 1.5B from Bybit ~1yr ago.
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
lxgr 5 minutes ago [-]
The reason subresource/web application integrity is not more commonly used is that there is no plan to actually do anything with it.
How are you going to verify your thousands of dependencies, some of them obfuscated/closed source? And if you can’t, what does integrity buy you?
amluto 27 minutes ago [-]
> Fundamentally: There is no way to lock webapps to reproducible builds.
One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.
dinosaurdynasty 22 minutes ago [-]
That's only meaningful if you are loading resources from a separate domain (e.g., a CDN or another subdomain).
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
This is completely unrealistic advice that 0% of people follow.
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...
What would happen if America got complete control of this system?
Oh wait. Oops.
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
For now most of these appear to be related to supply chain attacks which can be avoided with basic discipline and using features that browsers had for years: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
How are you going to verify your thousands of dependencies, some of them obfuscated/closed source? And if you can’t, what does integrity buy you?
One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
Wired's coverage (25 points) https://news.ycombinator.com/item?id=50296328
WSJ's coverage (20 points) https://news.ycombinator.com/item?id=50294287