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

211–216 of 216 posts

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

#211

Post by tptacek »

randomcarbloke wrote: post #205
tptacek wrote: post #46

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

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.

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

#212

Post by hnfong »

foooobaba wrote: post #175
hnfong wrote: 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…

Yes, perfectly sound and meaningless advice.

In practice, for example, I import openssl libraries to get mTLS, even knowing the history of CVEs they had over the years, because I know I'm definitely going to do a worse job at implementing it, and not implementing it is also worse.

So now, I knowingly included a bad-but-less-bad thing to avoid the bad-bad things. Now I have to keep myself aware of the bad things from the less-bad library that comes up from time to time in the form of CVEs. Those CVEs are "enumerating the bad". In theory I should be able to write a bulletproof mTLS library myself (or convince somebody else to), but apparently this thing doesn't exist, and the only real alternative is to wait for other people to enumerate CVEs from time to time and keep patches up to date.

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

#213

Post by rfoo »

zefix wrote: post #204
rfoo wrote: post #203

Earlier quoted context omitted.

Please tell me you have already thrown Firefox, Chrome, old Microsoft Edge and whatever browser out of window and are posting to HN with you rewritten-in-Rust lynx. Not being able to rewrite the world or convincing people to stop using memory unsafe languages is entirely unrelated to what security researchers do. I'd love to stop having to build complicated lifetime model in my mind to figure out whether there are hi…

No. We need to stop compromising. Yes, there is a lot of old code. No, I can't do it all on my own. But we can do it as a profession. Refuse to take jobs, nag managers, refuse to by hardware that only supports C, etc. If construction was as ridiculous our fiels, we'd still use asbestos.

> Refuse to take jobs

Well, I'm unfortunately not in a place where doing so makes sense. Unless you mean only auditing Rust code.

> nag managers

I already do so. This doesn't change much. There are still too many must-be-evolved C++ projects (no easy incremental rewrite path forward), it is impractical to have engs put significant effort into rewriting in Rust. It's really difficult to convince someone to fix something ain't broken.

People coding in C++ are just as desperate as you, that's why someone bring up Carbon [1], a half-baked experimental project to the world last year, instead of just using Rust. Sure, they would like to use a memory safe language as possible. No, they still have to get their job done.

> refuse to by hardware that only supports C

If it supports C, we can make it support Rust, it's a very fun weekend project to bring-up some nostd Rust code on it.

[1] https://github.com/carbon-language/carbon-lang

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

#214

Post by durnygbur »

bombolo wrote: post #207
mixmastamyk wrote: post #7

Earlier quoted context omitted.

What’s the deal with special chars? A site made me use one today.

Special but not special, don't you dare use a non ASCII character or the whole backend explodes.

Non ASCII special character?! Most systems which demand special character don't even allow all ASCII special characters...

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

#215

Post by wildmanx »

eduction wrote: post #169
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…

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

> > It hasn't aged well.

> You’re wrong, it’s aged quite well.

Part of the problem is that there are many people in the field of security with overly strong opinions. This is not healthy. The field is full of know-it-all people, with if-only-people-were-not-as-dumb kind of attitudes. This is not helping anybody. Any not-as-strongly-opinionated bystander looks at this and has no clue whom to listen to, since so many people are strongly expressing 100% opposing views. Calling everybody else "dumb". This is not helpful to bring the field as a whole forward.

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

#216

Post by mavhc »

autokad wrote: post #183
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…

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

It's dumb to create a system will fail because of dumb users, why did you invent a system that required everyone using it not to be an idiot, have you never met humans?
Post reply on HN