Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The six dumbest ideas in computer security (2005)

ranum.com

Post reply on HN
Print view View original

191–200 of 216 posts

Re: The six dumbest ideas in computer security (2005)

#191

Post by zefix »

josephg wrote: post #189
closeparen wrote: post #108

Earlier quoted context omitted.

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 ca…

Right; which is why all the things on that list are so important. We can’t seem to stop the endless flood of memory bugs in C/C++ code. Iirc 65% of security issues in chrome are due to memory bugs. But we can move to Rust and friends, where those bugs are a lot harder to write. We’ll never get the bug count to 0. That isn’t the goal. The goal is to get the number of in-the-wild exploited vulnerabilities as low as pos…

Well said: The point is to make a proper effort to make the tools we use better.

Humans will always make errors. Let's stop denying that and start fixing the mess we are making.

Re: The six dumbest ideas in computer security (2005)

#192

Post by optionalsquid »

bryanrasmussen wrote: post #185
optionalsquid wrote: post #144

Earlier quoted context omitted.

The article is from 2005, while NemID and MitID were rolled out around 2010 and 2021, respectively. That nit-picking aside, would you be willing to elaborate on your problems with the concept of NemID/MitID as a whole? And thank you for your work. The JS based NemID login was a huge improvement over the earlier, Java based implementation.

big unload coming - (tldr - maybe my nemid issues are just silly and paranoid and not really something that would actually happen, or maybe Danish criminals are not ambitious enough, and MitID issues are just the process for handling when you forget your password is broken) my problems with nemid - it just always struck me as a security issue that a large number of people were using their person numbers as their ids…

Thank you for the detailed answer.

With regards to the passwords, I somehow didn't catch that they were case-insensitive back when I created my account, so I used a mixed-case password for NemID for the longest time. Boy did I feel silly when I discovered this fact by accident.

I also didn't know that was how the recovery process went, and I can easily see it causing problems for a lot of people. I'd probably also have problems answering that kind of questions.

Re: The six dumbest ideas in computer security (2005)

#193

Post by josephg »

scotty79 wrote: post #102
josephg wrote: post #32

Earlier quoted context omitted.

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.

It was done for both reasons. Here's the Google Chrome comic book talking about it:

https://www.google.com/googlebooks/chrome/small_04.html

Another benefit they cite is reduced memory fragmentation. Because each tab lives in its own memory space, when the tab closes the OS can reclaim all of its memory. Presumably you'd still get framentation, but the OS is probably better able to handle that long term than jemalloc. Clever!

Re: The six dumbest ideas in computer security (2005)

#194

Post by chiggsy »

sbuk wrote: post #127
saagarjha wrote: post #82

Earlier quoted context omitted.

> The first time you see dialogues asking "Do you allow this app to open files in your Documents folder" its sort of annoying, but its a fantastic idea. It’s not a great idea because it’s annoying. It is not really useful in its current incarnation to most people.

Further, banner/modal fatigue is a real thing. People will just ignore and click through.

This is because the dialogs have gotten rid of the disclosure arrows that gave path information and metadata about the binary. Also, executables used to have names consistent with the naming conventions on the platform. Now you just get dialogs with some cryptic name, and a one line manpage.

Re: The six dumbest ideas in computer security (2005)

#195

Post by chiggsy »

denton-scratch wrote: post #135
sbuk wrote: post #113

Earlier quoted context omitted.

As key component of threat modelling is risk management and modelling. I would counter the “government blackmailing people” by questioning the risk this poses to me as an individual. As much as we’d like to imagine it, and as much as it can often times feel like it, we don’t live in a Kafkaesque society, by and large, as the significant majority of us are of zero interest and have little of anything worth blackmailin…

It seems to be routine for rape complainants to have to hand over their phone and have their messages scrutinized, as a pre-requisite to proceeding with an investigation. That is a form of government blackmail.

What? Where is this routine? Where do you live? What if you don't have a phone? Why would you give your phone to the police in this situation instead of the prosecutor?

Which government? What level? My god, who told you this thing? For what other crimes is this policy enforced?

Re: The six dumbest ideas in computer security (2005)

#196

Post by chiggsy »

sbuk wrote: post #171
denton-scratch wrote: post #135

Earlier quoted context omitted.

It seems to be routine for rape complainants to have to hand over their phone and have their messages scrutinized, as a pre-requisite to proceeding with an investigation. That is a form of government blackmail.

I disagree entirely with that notion. If you make a serious accusation, you must be prepared to hand over the necessary evidence to assist the investigation and get a conviction. I'll also say that at that point, the risk has changed dramatically. Risk isn't a static thing. It needs to be assessed regularly and evaluated when your threat model changes. Your exposure to risk is still a factor.

This is rubbish. The police investigate the claim and based on the results of the investigation, the prosecutor decides whether charges can be laid. The prosecutor!

Not the police!

Re: The six dumbest ideas in computer security (2005)

#197

Post by eduction »

tptacek wrote: post #184
eduction wrote: post #169

Earlier quoted context omitted.

> It hasn't aged well. You’re wrong, it’s aged quite well. Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for cond…

One of the major points of the qmail paper is that the structural locked down approach wasn't successful . (I disagree with the paper in this regard, but it's a weird thing to hang your argument against vulnerability research on). Georgi Guninski would have a thing or two to say about the applicability of vulnerability research to djb software.

Hi, that’s an interesting assertion but not actually accurate. It is vaguely related to the truth; djb acknowledges that qmail failed to partition in the way he advocates in the paper but says it survived without serious security issues for other reasons:

“ I failed to place any of the qmail code into untrusted pris- ons. Bugs anywhere in the code could have been security holes. The way that qmail survived this failure was by hav- ing very few bugs, as discussed in Sections 3 and 4.”

That’s very different from saying the approach wasn’t successful. It was just not tried (by him). My point is it has been tried in other ways since and seems to be working. To me at least!

(Also you took something I put in parens midway through my post with the opening words “see also” and said I “hang” my argument on it - ok, again interesting, not taking it personally as I’m sure you didn’t mean anything by it!)

Re: The six dumbest ideas in computer security (2005)

#198

Post by eduction »

rfoo wrote: post #170
eduction wrote: post #169

Earlier quoted context omitted.

> It hasn't aged well. You’re wrong, it’s aged quite well. Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for cond…

> (see also djb’s paper about qmail security) You mean the guy who refused to fix an integer overflow bug, claiming it isn't practical to exploit then 64-bit really happened then years later suddenly the fine guys at Qualys decided to have fun? [1] Sure, he is a crypto expert and we're all grateful for his work on curve25519, salsa/chacha, nacl, djbsort, etc (and I'm sure I missed a lot). This does not mean he is an…

No, I don’t mean the guy. I mean the paper.

Re: The six dumbest ideas in computer security (2005)

#199

Post by tptacek »

mytailorisrich wrote: post #125
tptacek wrote: post #26

A reminder that a big part of the subtext of this piece is a reactionary movement against vulnerability research that Ranum was at the vanguard of. Along with Schneier, Ranum spent a lot of energy railing against people who found and exploited vulnerabilities (as you can see from items #2, #3, and #4). It hasn't aged well. I'm not sure there's anything true on this list that is, in 2023, interesting; maybe you could…

> Ranum spent a lot of energy railing against people who found and exploited vulnerabilities That's not at all what #2 says. "enumerating badness" is explained as trying to track everything that's 'bad' instead of what's not. It is claimed to be 'dumb' because what 'bad' is orders of magnitude larger and more complex than what's not.

It's not what #2 says, it's just why he was saying it.

Re: The six dumbest ideas in computer security (2005)

#200

Post by tptacek »

eduction wrote: post #197
tptacek wrote: post #184

Earlier quoted context omitted.

One of the major points of the qmail paper is that the structural locked down approach wasn't successful . (I disagree with the paper in this regard, but it's a weird thing to hang your argument against vulnerability research on). Georgi Guninski would have a thing or two to say about the applicability of vulnerability research to djb software.

Hi, that’s an interesting assertion but not actually accurate. It is vaguely related to the truth; djb acknowledges that qmail failed to partition in the way he advocates in the paper but says it survived without serious security issues for other reasons: “ I failed to place any of the qmail code into untrusted pris- ons. Bugs anywhere in the code could have been security holes. The way that qmail survived this failu…

It didn't "survive" in that manner: it wasn't LP64 clean, and had memory corruption vulnerabilities.
Post reply on HN