Hacker News Reader

Agree with tptacek. His rant in Enumerating Badness is deeply intertwined with his rant against Default Permit (which as tptacek points out, was a bit of a strawman even then). I could agree that checking against all possible bad things is a flawed approach for security products and IT staff.

However, enumerating badness is hugely valuable in the security industry for two reasons:

1) It’s the backbone of security research, just as physiology and anatomy are to zoology and medicine. With enumeration (observation), we can classify, abstract, find trends, identify risky software and approaches, direct engineering resources, and create broad defenses (yay ASLR).

2) Attackers are lazy, too. I work at a security consulting firm, and routinely see attackers reuse the same TTP across different target companies. Enumerating badness not only offers detection opportunities (perhaps not the best, but higher level detection techniques are often built off understanding the enumeration of badness) but also denies attackers opportunity for reuse. “Impose cost,” as thoughtlords like to say.

> Objecting to user education is an idea that is coming back into vogue, especially with authentication and phishing. It's the idea that has held up best here.

This can be good or bad depending on how you do it. If you default to the good thing and there really isn’t any need to do the bad thing then it can be quite good. If there is a genuine need for some people to sometimes do the bad thing (so it’s not actually universally “bad”) pretending like nobody can ever make an informed decision here is not a good policy. Sure, it’s very difficult to get people to make informed choices, but you can’t really brush this off as people being uneducateable.

you can’t really brush this off as people being uneducateable

The objection isn't that people are uneducable, it's that even expert users can easily make seemingly-trivial mistakes which then have catastrophic consequences (e.g. experts get phished) and that's a conclusion reached through experience/data.

> 1. Default deny is one of the oldest best practices in security engineering; it barely needed saying in 1995 (but Cheswick & Bellovin said exactly that in Firewalls & Internet Security).

I agree with this as the theoretical grounding and certainly wouldn't say that this was especially insightful but I can understand why he said it if he was encountering a long tail of obsolete advice similar to what several places I worked were hearing at the time. I think one of the big problems was simply inertia: I remember the Cisco guys at one job saying they didn't want to do a default-deny policy because it was too much work to switch and they weren't sure if the hardware could handle that many rules.

> Objecting to user education is an idea that is coming back into vogue, especially with authentication and phishing. It's the idea that has held up best here.

The notion that users can't really be educated has led to a lot of questionable security practices that prioritize ease of use over real security. For example, 2FA using codes sent by email or SMS as the second factor rather than relying on key based authentication like client side TLS certificates issued by the service that the client is using.

This, to some extent, has actually decreased security by allowing people to bypass authentication by compromising the second factor through use of social engineering.

My bank used client TLS certificates early on, while it is nifty it was a really bad idea without hardware security. (Paper OTP in their case)

IMHO, client side certificates are a big failure even on server to server. The UX of doing it is error prone and insecure because of foot guns. It fails because there are so many different incompatible ways to use them. Mostly this idea of mine is based on never having had a good experience with browser based client certificates (even highly automated and hardware secured ones). Things does not get much better on server.

Sure automation helps but the certificate is a such a small part of the system, and when you try to integrate two automated systems that use client side TLS certificates it is easy to trust too much or too little. (Both are troublesome)

> The UX of doing it is error prone and insecure because of foot guns.

Many people over the years have mentioned UX issues as a reason why client side TLS certificates aren't more widely used. The question is why hasn't there been an effort to improve the UX rather than re-inventing the wheel (either poorly with SMS/email 2FA or OTP, or in a way that's limited to a specific application level protocol like HTTP for webauthn).

What I would like to see is a standard workflow where as part of an account creation process, an associated CSR is sent and a client side TLS cert is returned and stored on the device along with a standard way to add additional devices using an existing device and the new device that doesn't depend on a specific application level protocol (so, for example, I can use my email client via SMTP and IMAP to securely authenticate without having to rely on a HTTP intermediary).

Or, for more secure settings, actually having to verify your identity out of band (e.g., going to the bank and showing multiple forms of ID along with your CSR to get the certificate.

The problem is basically that it wasn’t a priority for application developers but you need to upgrade things everywhere before you can switch to a new protocol. Those clunky MFA options give CIOs the appealing promise that a bit of duct tape means they get some protection without needing to e.g. replace that old RADIUS server most people depend on to do their jobs.

It might be interesting to look at WebAuthn passkeys, as they do most of what you want. That took several important developments: the web ate desktop apps, Microsoft lost control of the web, and Google has some strong security people in their management. That does the public key exchange, has robust cross-device support which doesn’t require an internet connection, etc. and it has some features to improve the identity situation (e.g. it includes a device key & authentication info so my bank can say it only accepts transfer requests which came from a known device doing a biometric check, which is a nice edge over x509/SSH-style trust based solely on access to the private key).

This unfortunately does not work using other protocols but a not-uncommon flow would be using a browser session to issue your IMAP client a token. That’s not great (a compromise gives the attacker your email) but it can be less disastrous if the most important actions can’t be initiated purely from email.

Apple/etc Passkeys (WebAuthn in software instead of hardware tokens) seems similar to TLS client certs, so I'm sure the UX stuff with certs is solvable if anyone cared.

They are, but they require one to use the HTTP application level protocol. I would like to be able to do the same with SMTP and IMAP in my email client without having to make HTTP requests.

> 4. "Hacking is cool": literally, this is "get off my lawn".

I do not quite agree with this verdict. Back in the early two thousands there were lots of people who thought it rather cool to just hack around (or more precisely crack around), for example by exploiting SQL injection bugs in whatever web form they encountered.

Of course I might not have a representative impression of the community, but I think this kind of stuff is now much more widely seen as unethical and uncool. So I think the article's prediction that this will "be a dead idea in the next 10 years" was actually quite accurate.

It's actually hard to argue here given there is so much ambiguity.

Technically "hacking" is often portrait as totally cool and often not negatively connotated ("getting/being hacked" however clearly is). The problem with this is that the meaning has shifted a lot in the meantime. He means mostly cracking I think, while the meaning of "hacking" has shifted to be broadly just altering state/behavior often to something that was not originally intended.

At least he also includes penetration testing as something bad and this has clearly not aged well. For one you can also employ people to do just that and it's pretty essential for applications with big security implications and the other part is the invitation to "hack" the application/system at hand seen with bug bounty programs. The actual practice seems to contradict his point here.

You can also interpret it in a way that it is not going to improve your security just by virtue of having pen testing, which is true. However I feel like nobody argued that. Pen testing/bug bounties are there to actually get attention of exploits you might not get otherwise and therefore a prerequisite for fixing exploits. Or said differently: If you think you hardened your application/system so much that it's impenetrable, how could it hurt if people try to break it and tell you if they are able to. People will try anyway, but they might not tell you.

4/6 and it hasn't aged well?

1 might be ubiquitous even in 2005 but it's 2022 and this was the page that was shared, obviously it was worth Ranum stating...

The things that are true aren't interesting, and the things that are interesting aren't true.