Recent submissions

Comment · 9 days ago
"Should" is doing a lot of heavy lifting there. Most shops are a long way off from secure coding, and from my experience in the last 10 years most devs lack basic awareness of security. I still see people being surprised by OWASP Top 10 or simple things like trust boundaries.

There's no guarantee AI will find existing vulnerabilities proactively during coding, or that it won't introduce new vulnerabilities in the process of shipping features. You're right that shops _should_ be critical and test code, but I think due to the lack of awareness people will end up implicitly trusting any first pass written by AI and not bother to double check it.

Comment · 9 days ago
Hence why I said the studies here are quite old, and I'd like to see something more recent, though I guess it'll be some time before that's done.

I think most people writing code with AI nowadays will find it's still lacking in some areas. Not because the model isn't good (definitely miles ahead than what we had access to in 2022-2023), just because it wasn't actively mentioned and so the model skipped over it. The same will apply to security.

Comment · 9 days ago
Bold of you to assume that AI-written and -reviewed code doesn't introduce new vulnerabilities. I think after we're done with this stretch of finding human-made vulnerabilities, we'll have a long road ahead to clean up the mess that's introduced by AI.
Comment · 9 days ago
It's been shown to be bad at secure coding _unless_ you specifically prompt models to watch out for common vulnerabilities, at which point they're actually quite good at containing the issues, though the studies here are somewhat older (eg https://arxiv.org/abs/2211.03622).

The issue then is that most people aren't actually good at keeping an eye out for security issues in code proactively, so things slip through the cracks (whether human-written or not), just at a much accelerated pace.

Comment · 9 days ago
Say what you will about OpenAI, Wiz etc but if OpenAI, Wiz, Cloudflare, the PHP Foundation and pretty much every CERT out there together recommend to take down PHP apps and patch immediately then I'm very much inclined to follow that advice.

Due to the insane media coverage there'll of course be a deluge of PoCs, most of which won't work. But constantly refreshing Twitter to see whether there's a working PoC is not a good use of time nor a great security strategy.

Comment · 9 days ago
To be fair, the warning to either take down websites or patch immediately on release came from the people who've been working on this for months (or those with advance notices like CERTs), not out of nowhere. People just took it down pre-emptively since exploit attempts (whether working or not) popped up in logs way before the patch was released, but it also took forever until the fix actually landed downstream after the advisories were released.
Comment · 9 days ago
I think people are just latching onto the post that hit the front page earlier today about it being non-trivial to exploit, combined with the fact that there seem to be about a billion PoC out there, most of which don't work.
Comment · 10 days ago
Are they, though? I seriously doubt some sysadmin is going to look at this and say "Maintainers said to patch, but clearly _this guy_ knows better, so I won't."

Besides, he's got a point. The initial PoC that kept popping up on Mastodon (the ones he linked in the post as well) simply didn't work. One of them even posted an updated exploit later that still didn't work, but supposedly meant the vulnerability went from CVSS 10 to CVSS 4.

Comment · 10 days ago
Lots of places where Senior just means 3+ YOE and anything more than that has even fancier titles like "Staff" or "Principal".
Comment · 26 days ago
„Let me ask my LLM“
Comment · 2 months ago
Satellite Reign was fun. Not sure if I'd call 2015 _recent_ though :)
Comment · 2 months ago
Hi HN,

Over the last few months, I invested pretty heavily into setting up SSO for my self-hosted stack. However, some apps gate SSO behind paid plans, meaning accounts and thus MFA need to be set up outside of the IdP. This leaves me with a weird mix of accounts handled by the IdP and those that I need to track manually.

There wasn't really a good way to track this mixture, especially once you add multiple MFA devices and sensitive data like recovery codes, because the IdP has one half and the password manager has the other (+ maybe it's the second factor itself).

That's why I built RecoveryCodes. It allows me to track all my accounts, see which MFA devices I've enrolled (I usually enrol 2 per account, in case one is lost) and also gives me a place to store recovery codes (instead of copy pasting them into a random .txt file).

Obviously I'm n=1, so I'm interested in hearing from slightly larger companies how you're dealing with this mix? Spreadsheets maybe, or are most of the accounts covered by IdPs and the rest don't really matter?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton