That hasn't aged well, at all, lol.
The first two points are alright, then it just veers off the rails
The six dumbest ideas in computer security (2005)
101–110 of 216 posts
Re: The six dumbest ideas in computer security (2005)
#102I wonder how well we all think this article has aged? "Penetrate and Patch" is supposedly dumb. But what do we practically do with that? We've seen in the last decade or so a lot of long-lived software everyone thought was secure get caught with massive security bugs. Well, once some software you depend on has infact been found to have a bug, what's there to do but patch it? If some software has never had a bug found…
I think this article has aged very well. > Also web browsers face a constant stream of security issues. What are we supposed to do instead? There's not much that users can do, but web browsers have spent the last decade moving away from "Penetrate and Patch" to much more proactive approaches. Eg, Chrome pioneered moving each tab to a separate process with full sandbox isolation. Firefox is talking about using webasse…
> Chrome pioneered moving each tab to a separate process with full sandbox isolation.
I don't think it was done for security. Before chrome where all tabs ran in single process it was common for a bad site to stall your whole browser. Separating it into single processes was basically admission that, yes, web browser sucks, so the best we can do is give you ability to kill a part of it when it misbehaves.
Re: The six dumbest ideas in computer security (2005)
#103Earlier quoted context omitted.
The fundamental flaw is normally "but doing it correctly would cost too much and take too long, what can we do for $5 and a chocolate bar?". Airline projects don't have the same level of issues because the FAA (or equivalent domestic authority) tells them to do it correctly.
Except when they don't, then you get the Boeing 747 MAX literally avoiding mandatory safety evaluations and ignoring engineers
But that is notable for being unusual.
After the FAA agreed that the two crashes were similar it grounded all planes, revoked Boeings certification authority, and fined Boeing.
Has Lastpass received anything other than bad publicity?
Re: The six dumbest ideas in computer security (2005)
#104Earlier quoted context omitted.
The fundamental flaw is normally "but doing it correctly would cost too much and take too long, what can we do for $5 and a chocolate bar?". Airline projects don't have the same level of issues because the FAA (or equivalent domestic authority) tells them to do it correctly.
Is there any real equivalent process for tech? It seems like the majority of security certifications is a box checking exercise where actually being secure has very little relation to how many boxes you checked.
[deleted]
Re: The six dumbest ideas in computer security (2005)
#105Not convinced these are the dumbest (none of them is quite as dumb as requiring special characters in passwords, for example, and I'm not sure the fourth is dumb at all), or that they're six ideas. The first two are the same, and the third one is a special case of the same thing.
Yeah, and they didn't mention "storing your passwords in plain text"
And 'security through obscurity'.
Re: The six dumbest ideas in computer security (2005)
#106Earlier quoted context omitted.
> 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 authentic…
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 g…
> 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.
Re: The six dumbest ideas in computer security (2005)
#107Earlier quoted context omitted.
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 g…
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.
Re: The six dumbest ideas in computer security (2005)
#108> "We can't stop the occasional problem" - yes, you can. Would you travel on commercial airliners if you thought that the aviation industry took this approach with your life? I didn't think so. This person has a fundamentally mistaken idea of how airliners and, therefore, security systems as a whole work. Yes, airliners have the occasional problem. That's why they have: * checklists and inspections, to catch them bef…
> "We can't stop the occasional problem" - yes, you can. All those tools (checklists, redundancies, etc) exist to increase the reliability rate. And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1]. I might be overly generous, but thats my read of the author's intent. That just like in the airline industry, we have tools to stop occasional problems from turning into…
As long as software has bugs and accepts user input, there are going to be ways to make it do things it shouldn't. You can avoid running specific known vulnerabilities. You can avoid creating certain kinds of dumb and obvious ones. But barring, like, formal verification, it is always possible for someone smarter or more patient than the original software development team to think real hard and come up with an edge case they didn't. And operational or system-level controls can only do so much about that.
Preventing every security vulnerability is the same problem as writing bug-free code. And that is manifestly not happening, not even in the most sophisticated software development operations in the world.
Re: The six dumbest ideas in computer security (2005)
#109Earlier quoted context omitted.
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). 2. "Enumerating badness" is simultaneously an attempt to connect vulnerability research to antivirus (security practitioners have had contempt, mostly justified, for AV since the late 1980s) and an endorsement of the heuristic detect…
> 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 u…
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.
Re: The six dumbest ideas in computer security (2005)
#110Earlier quoted context omitted.
> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…
Linux has lots of protective measures outside of just user isolation. There's capabilities, namespaces, cgroups, seccomp, landlock, selinux, apparmor. The difference is Linux gives the owner of the machine (for better or worse) decide what to do here. There are distros that try to force you into a more secure posture (Qubes), though.
This is interesting to me. Do you know if Windows OS provides similar features? The ideal for corporate environments (outside of dev) would be desktops that operate in the same way as iOS.