Live data from Hacker News

The six dumbest ideas in computer security (2005)

ranum.com

181–190 of 216 posts

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

#181

What I think happened is that with computing, humanity began to build a new world, a Different World that's not like the other, old world outside. But since humans were building it, it became just like that. It has the same buildup, the same issues, the same dumbness as the original, real world. #1: Default permit: people don't like to spend energy, especially not upfront. Integrating "Permit by default" systems is m…

> It has the same buildup, the same issues, the same dumbness as the original, real world.

Why would it not? Both computers and humans exist in the same world. There is no 'towing it outside the environment', we are the environment and all of our warts and problems are going to follow.

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

#182
post #163

Earlier quoted context omitted.

What do we do in practice? - Personally audit all the 392 library dependencies in our project to make sure they don't do anything dumb? - Ask the intern to write a non-dumb logger (and the other 392 deps) from scratch? - Don't use dependencies and write bare metal assembler? (JDK, libc, OS kernels are dependencies and do introduce a steady stream of CVEs) - Give up on doing anything complicated and congratulate mysel…

Well, it isn’t easy and there is no silver bullet. In practice must use your engineering judgment and THINK about these tradeoffs for every problem you encounter. That being said, there are some principles you can think about to help you get the tradeoffs right when you encounter a problem. The main principal the author discussed is the idea of enumerating the good, rather than enumerating the bad. Deny everything ex…

>So basically in practice think carefully about the risks, costs, benefits and what tradeoffs are worth making.

And then be told by management to scratch that, we need the app out yesterday or the competitor is going to eat us.

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

#183
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…

I agree. they go onto a useless rant about how pen testing is useless, red team research only enables hackers, etc. That's not true at all. That work is what pushes the improvements in both detection and better programming practices.

Educating users is not dumb, its one of the most important parts of security a company should address. I really don't know where they are coming from here, this section was nonsense to me.

I also have a point that will get me downloaded and piss off a lot of people, Security is very important, but not THAT important. If the business doesn't operate, then there's no need for security. So what's the solution? The author comes off as one of those that treat security like a wheelbarrow full of bricks that everyone has to push around. This wont get buy in and people will find ways around it. Instead, security should be like tennis shoes. restrictive but they also allow you to run faster.

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

#184
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…

> 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.

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

#185

I feel let down as a Dane that neither NemID or MitID deserve a mention. https://www.nemid.nu/dk-da/om-nemid/historien_om_nemid https://www.borger.dk/internet-og-sikkerhed/mitid full disclosure - I worked on the JavaScript implementation of NemID. My problems with it are not the implementation, but the whole concept.

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 for nemid services - sure you could change but not sure how many did. The passwords they used were case insensitive and it was played up that you didn't need to worry about that, it could be real simple so the only real line of defense was the nøgle card, which a lot of people also used the paper version.

Personally if I'd been a crime lord during NemID's heyday I would have tried to get pictures of rich people's nøgle card, have burglars hit the whiskey belt, - you find a card take a picture, then the only real issue is finding the id and password - id is probably personnummer, password is probably simple and might be easy to find (or put some spyware on their computers) But this didn't happen as far as I know so maybe there are reasons why it isn't that good a plan anyway and I'm just like a paranoid guy.

MitID bugs me because of the process when a user forgets their login or something otherwise goes wrong, which is that you get random questions from the personal register in borger.dk, my wife (who is Italian) had a problem with her MitID had to reset she got asked what her address was, and what her children's names were - which I submit would be real easy for an attacker to find out.

I had a problem I got asked my mother's maiden name, what age she got married at, what month she was born, where I live, what year and month we moved in our house, and what sogn I was baptised in.

Now I submit those questions are reaaaallll cool and easy to answer for any good and proper Danish family that have never had any problems for the last few generations but as it happens I was estranged from my parents. I don't offhand know where I was baptized (I was born in Rigs but baptized somewhere in Jylland because of a trip to visit grandparents IIRC), I'm not sure when my mother married my father - if she was 18, 19, or even 20. I couldn't remember what month she was born but my wife could because it was the month before her mother was born.

We rented our house for nearly 9 months before buying, so trying to remember again what exact month we bought it in would be difficult and of course we had transferred our address to the house before purchase because we were living there and intending to buy but the person asking the questions wouldn't even answer if what they wanted was when we said we were living there or when we bought the house, but they did urge that I should "take a guess".

The process as I said is beneficial for people with perfect families, but say a family where people got divorced and didn't talk to each other and were drunks like mine, I get screwed over by that process. The process is, it seems also beneficial to people from outside Danmark as they will of course have a less extensive record in borger register for random questions to be drawn from, hence the easiness of the questions my wife received.

I have requested clarification from Digitaliseringsstyrelsen as to what the background and technical discussion was related to the decision to use these randomized questions as I would like to write a longer article about how stupid it is, also because I can think of several ways in which I think malicious actors might be able to get access to that data relatively easily and answer the questions easier than an average citizen.

But they don't seem to understand what I mean when I say I want the background and technical discussion - which I mean I want the kind of meeting notes that go on when implementing a standard (such as when I worked on Efaktura when one element was considered informative but unfortunately that did not make it into the bekendtgørelsen, but we obviously had those meeting notes to refer to as to how it was informative and not to be used in any calculation of the faktura)

on edit: I have done a mix of English and Danish here, mainly English so everyone can follow; some Danish terms because I figured not that important.

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

#186

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…

so I want some notes where one senior guy says I think we should pull randomized questions from the citizen data, and either everyone says that is a great idea, or there is a bunch of discussion about it and they actually bring up the points that I find painful but they have smart reasons why that is the way it has to be anyway - or somewhere in between these two poles.

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

#187
post #171

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.

> hand over the necessary evidence

Of course. But you shouldn't have to spill your guts about your entire life (I understand that young folk nowadays life their lives in Instagram selfies).

And more to the point, the first step for the policemen investigating a rape complaint should be to investigate the complaint, not the complainant. If the investigation of the complaint raises questions about the complainant, then there might be grounds for seizing the complainant's device. But they can't make device seizure a pre-requisite for doing their job.

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

#188
post #89
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…

What was the argument against vuln research? The 'Penetrate & Patch' bit makes it sound it's something like 'this is pointless because the proper way to fix this stuff is better design and other things are a waste of time and effort'.

This is a whole can of worms, and my response will be biased and untrustworthy, but here's my take:

In the early-to-mid 1990s, serious security research was intensely cliquish. There wasn't a norm of published vulnerability research; in fact, there was the opposite norm: CERT, the well-known public resource, diligently stripped details about vulnerabilities (beyond where to find the patches) out of announcements, and discussions about how vulnerabilities actually worked was relegated to "secret" lists like Core, which were of course ultimately leaked to became BBS tfiles.

Ranum came to prominence in that era. In the mid-to-late 1990s, after Bugtraq took over, there remained a sort of informal best friends club of, like, Ranum and Dan Farmer and Wietse Venema and like one or two young vulnerability researchers --- Elias "Aleph One" Levy, for instance. There was a sort of acceptance of the idea that Elias and Mudge were doing vulnerability research that was well-intentioned and OK... but that everyone else was just trading exploits on #hack.

There was a sort of focused beam of hatred on eEye, a security vendor that came to prominence in the early 2000s, and most especially during the "Summer of Worms", some of which worms were based on vulnerabilities that eEye's team --- at the time truly one of the most influential teams in all of vulnerability research --- had published. I worked at the industry's first commercial vulnerability research team and had a soft spot for eEye, which was doing the work we did but like several levels better than us, and it has always pissed me off how Ranum and Schneier tried to make hay by dunking on eEye and casting them as "hackers".

(Of course, if you tried to make that argument now you'd sound like a clown, so you won't see people like Ranum and Schneier saying that kind of stuff. But the fact is, the arguments were clownish and inappropriate back then, too.)

So, if you ask me, the argument Ranum is advancing is literally that public vulnerability research is bad, and that details of vulnerabilities should be kept between vendors and a few anointed 3rd party researchers. Because otherwise, you were just helping people break into computers.

The Ranum of 2005 is I think especially characteristic of what I'd call "moralizing" information security; that security is actually a fight between good and evil, that what's important about machines getting owned up is that somebody's livelihood depends on that machine running, and the hacking is a crime, and the details of how the hack worked are about as relevant as the details of how a burglar breaks into the window of a house they're burgling without setting off the alarms or whatever. I get it, but I'm from the opposing school of information security, which is that security is just a super interesting computer science problem.

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

#189
post #24

Earlier quoted context omitted.

> "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 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 possible. And there’s all sorts of ways to move the needle on that, which don’t require humans to suddenly become infallible.

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

#190
post #89

Earlier quoted context omitted.

What was the argument against vuln research? The 'Penetrate & Patch' bit makes it sound it's something like 'this is pointless because the proper way to fix this stuff is better design and other things are a waste of time and effort'.

This is a whole can of worms, and my response will be biased and untrustworthy, but here's my take: In the early-to-mid 1990s, serious security research was intensely cliquish. There wasn't a norm of published vulnerability research; in fact, there was the opposite norm: CERT, the well-known public resource, diligently stripped details about vulnerabilities (beyond where to find the patches) out of announcements, and…

I thought when asking to maybe snarkthrow in a 'this wasn't about disclosure, was it' but then I thought I would sound like a clown asking such a thing about a piece from 2005. Entirely externally/cluelessly my impression (at the time and since) was this was settled in the 90s by things like Bugtraq - that disclosure aligns with the interests of users in critical ways that leaving it up to vendors doesn't and this easily trumps objections about 'responsibility'. I didn't know this went on for so much longer, thanks for the history!
Post reply on HN