17 ms·

The six dumbest ideas in computer security (2005)

• ghostpepper 4y ago
  According to Slashdot this article was online since at least September 2005. I would be interested to hear the author's thoughts on what has changed in the 18+ years since it was written.
  • deathanatos 4y ago
    Oof, well, I was going to say, > My prediction is that the "Hacking is Cool" dumb idea will be a dead idea in the next 10 years. … that won't age well, and apparently, that didn't age well. It won't happen in the next 10, either. Nor will good engineering: as an industry, we a.) dislike the very idea that knowledge is required for software engineering and b.) every "Rust fixes this entire class of bugs, permanently" "oh god not the Rust evangelists" … yeah, the bugs will continue.
• m463 4y ago
  If I could come up with one dumb idea it would be something like: You can trust large-organization to secure your device. (especially for orgs that give themselves, advertisers or apps more access to the device than you have)
  • deleted 4y ago
    [deleted]
  • yjftsjthsd-h 4y ago
    I dunno, the question is "against what?"; I trust a Chromebook to resist an evil maid attack, but not to stop an advertiser from stalking the user. Some people are okay with that threat model.
• lmm 4y ago
  Not 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.
  • geoduck14 4y ago
    Yeah, and they didn't mention "storing your passwords in plain text"
    • scotty79 4y ago
      And 'security through obscurity'.
  • mixmastamyk 4y ago
    What’s the deal with special chars? A site made me use one today.
    • bombolo 4y ago
      Special but not special, don't you dare use a non ASCII character or the whole backend explodes.
      • durnygbur 4y ago
        Non ASCII special character?! Most systems which demand special character don't even allow all ASCII special characters...
  • rippercushions 4y ago
    I've been looking for a new bank in the last week. Actual password practices I have encountered in 2023: * ME Bank: Password must be between 6 and 20 chars long and consist entirely of numbers * Westpac: Password must be exactly six (6) characters long, letters and numbers only
• edrxty 4y ago
  Looking back on that era, the hate towards hackers feels really misplaced. Yeah, at the time it was more local and more dominated by people doing it for the lolz but we kinda owe them a debt of gratitude. If they hadn't gotten everyone to stop being lazy about security we'd be in a very different place now, surrounded by rouge states and agencies launching hyper sophisticated attacks on infrastructure and data. That was also the era that trained the current generation of cybersecurity experts.
  • pookha 4y ago
    It wasn't misplaced...There were some horrific pieces of "hacker" software that were floating around in 05. Wasn't uncommon for a disgruntled employee to load malware onto a company's network and bring down operations for weeks. Case in point, douchebag loaded a maleware into this small financial company's network that I wound up working for. The virus infected the boot sector and forced the company to do low level formats on all of the company's hard drives. They lost immense amounts of money and respect in their industry and barely recovered. That virus was developed by some garbage hacker boy for laughs.
    • edrxty 4y ago
      In fairness, there aren't a whole lot of ways left to run around corrupting the boot sectors on an entire network. Given current politics I'd rather have everyone learn how to enforce user access control in '05 rather than in '23.
• ufmace 4y ago
  I 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 in it, does that actually mean that it's secure, or just that no skilled hackers have ever really looked hard at it? Also web browsers face a constant stream of security issues. But so what? What are we supposed to do instead? Any simpler version doesn't have the features we demand, so you're stuck in a boring corner of the world. "Default Permit" - nice idea in most cases. I've never heard of a computer that's actually capable of only letting your most commonly used apps run though. It's not very clear how you'd do that, and ensure none of them were ever tampered with, or be able to do development involving frequently producing new binaries, or figure out how to make sure no malicious code ever took advantage of whatever mechanism you want to use to make app development not terrible. And everyone already gripes about how locked-down iOS devices are, wouldn't this mean making everything at least that locked down or more?
  • munchbunny 4y ago
    The points didn’t age well, but there’s a kernel of truth in there: none of those things will ever work 100%, so if you’re trying to really lock things down you need defense in depth, which was also not a new security concept in 2005, but it was one we were, as an industry, less sophisticated about.
    • denton-scratch 4y ago
      "Defence in depth" is a term with obvious military origins. You have a relatively thin front-line of defence, with orders to fall back if they are in danger of being overrun. Then you have a very strong second line, manned with assault troops. As the first line falls back, the second line counterattacks. This strategy was developed by the Germans in WWII, and adopted by the Russians. I disapprove of it's use in computer security. There, it means something different; it means basically having multiple lines of defence, without any notion of counterattack.
• sweetjuly 4y ago
  >Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? Sure, but how does one get the knowledge on how to secure systems? Half the job of a security engineer is thinking like an attacker and trying to poke holes in it. Key mitigations like ASLR and stack canaries are so effective because they specifically block off key resources and techniques that attackers use. It would be downright impossible to invent these mitigations (or even meaningfully understand them) if you did not already have a firm grasp on memory corruption and ROP. I'm not sure it's an argument I actually care to defend, but I do honestly believe that you can't be a strong security engineer if you don't have a grasp on the techniques your adversaries use.
  • riffraff 4y ago
    This confused me too, my interpretation is that the author is saying you should not invest time in learning how to use the exploit or scanner du jour. Being aware of the new hacking techniques is ok, but I think this is arguing against vulnerability scanning tools.
  • worthless-trash 4y ago
    As a security engineer, I can't agree more. If you dont understand your enemy, you can not hope to defend against them.
  • foooobaba 4y ago
    With respect to this example, I think he is saying it would be better if we were using memory safe languages, rather than trying to come up with these sorts of mitigations (which is enumerating the bad). Of course it’s probably not possible in every scenario because we’ve been doing it badly for so long, but I think the principle still holds.
    • rfoo 4y ago
      Of course we can avoid all the lasting architecture mistakes we made if we knew it before and had been doing it correctly since the beginning. And it's practical, right? Right? See, when there are no "system security" word on it people suddenly start to make sense of it. I'm glad that we are reviewing this 2005 post in 2023 though, at least we can fight hindsight by hindsight. </rant>
• msla 4y ago
  > "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 beforehand * communications, to catch them while they're evolving * redundancies, to turn ramified problems nobody caught into annoyances instead of disasters No matter how some people whine and moan, "Just Be Perfect" fails to be an actionable plan. Also: Hackers will be cool as long as DRM and planned obsolescence/designed-in insecurities exist.
  • acdha 4y ago
    It sounds like you’re disagreeing but you’re restating his point: all of the things you listed are how rare events are prevented from becoming worse.
    • msla 4y ago
      I am disagreeing because this person doesn't understand the concept of defense in depth: Occasional problems will happen, will ye or nil ye, and the best you can do is to, as you say, prevent them from becoming worse. Thinking airliners don't have occasional problems is missing a lot of what the air industry does that we can implement in other realms.
      • acdha 4y ago
        He clearly does elsewhere, so I would suggest reading this more charitably with the assumption that you’re talking about the same idea from different perspectives. If I’m the passenger, I don’t even know about something which is caught by a checklist or redundant hardware before it progresses. If I’m the pilot or mechanic, the reverse is true. In both cases, what matters is the spirit of the point: saying something is too infrequent to prevent is defeatist.
        • msla 4y ago
• deleted 4y ago
  [deleted]
• saghm 4y ago
  It's super interesting to read this list as someone young enough that the first time I was ever prompted to consider computer security was in a college course almost a decade after this was written. Although different terminology was used, some of the ideas, like "Default Permit" and "Enumerating Badness" were so heavily discouraged when I first started studying that it's almost hard to imagine them being considered good practice so recently before (although even today they're common enough that it's still worth calling out, so maybe this wasn't uncommon knowledge at the time either). On the other hand, the next two ideas, "penetrate and patch" along with "hacking is cool" certainly don't seem to be as reviled as the author would like, and I don't think that the latter was a dead idea within a decade like they suggested. Trying to interpret them charitably, I could believe that the intention here was to decry the lack of proper threat modeling that was done in advance at the time (which still is a real issue today). On the other hand, reading it at face value sounds like the idea that if you think enough in advance and just "don't write bugs" that your product will be 100% secure and never need any patching, which I don't think is a good take. I'd counter that it's essentially the same as the fallacy they mention later, "We don't need host security, we have a good firewall"; proper design up front is a good "firewall" to stop bugs from coming in, but it's not a substitute for having proper mitigations for when they do inevitably occur.
  • acdha 4y ago
    I’m feeling old remembering reading this at the time and being glad that it was getting pointedly directed to certain large vendors. I think the key part of “penetrate and patch” is rejecting the idea that you can hire a tester, patch a couple of holes, and otherwise not change anything. It’s the difference between being _shocked_ that your C++ has another memory safety issue after someone exploits it or using tools like Rust, sandboxes, static analysis, etc. to avoid having an exploitable vulnerability in the first place. The major confound here is that a lot of companies realized there aren’t actually many penalties for releasing unsafe software, and decided that throwing bodies at patching was cheaper. I’m reminded of how many antivirus programs had basically 90s-level C code running with system privileges because the owners decided it’d cost too much to rewrite it until Tavis Ormandy started fuzzing them. I doubt many customers switched despite clear evidence that those vendors had serious deficiencies in their development processes.
• dang 4y ago
  Related: The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=28068725 https://news.ycombinator.com/item?id=28068725 - Aug 2021 (21 comments) The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=14369342 https://news.ycombinator.com/item?id=14369342 - May 2017 (6 comments) The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=12483067 https://news.ycombinator.com/item?id=12483067 - Sept 2016 (11 comments) The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=522900 https://news.ycombinator.com/item?id=522900 - March 2009 (20 comments) The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=167850 https://news.ycombinator.com/item?id=167850 - April 2008 (1 comment) The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=35811 https://news.ycombinator.com/item?id=35811 - July 2007 (2 comments)
  • efitz 4y ago
    Yep, it’s worth repeating. Although I’d spin the issue about host vs network security differently. I’ve found that engineering teams prioritize security a lot more if they don’t feel like they’re safe in a cocoon of local network bliss behind network firewalls. I love “beyond corp” or “zero trust” precisely because you’re making it explicit that they’re on the internet and they’re a target.
    • deleted 4y ago
      [deleted]
    • arp242 4y ago
      > Yep, it’s worth repeating. I don't know; I haven't really seen most of these things in the wild for a long time. For "#4) Hacking is Cool" the zeitgeist has moved in the exact opposite direction with "white hat", bug bounties, etc. I think that section in particular is a pretty outdated view of things. "#6) Action is Better Than Inaction" is probably the only one that still broadly applies today, and is actually a special case of "X exists, therefore, therefore we must use it ASAP, and any possible negativities are not our problem and inevitable anyway" attitude that seems the be prevalent among a certain types of people.
• quickthrower2 4y ago
  User education is not dumb. Services that send test phishing emails and check that people mark them as such are a good idea. It gets people used to receiving suspect emails and dealing with them.
  • adql 4y ago
    Especially considering most big breaches appear to be "some human somewhere fucked up"
• tptacek 4y ago
  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 argue they were in 2005. The irony is, Ranum went on to work at Tenable, which is itself a firm that violates most of these tenets.
  • pvg 4y ago
    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'.
    • castillar76 4y ago
      This predated a lot of the responsible-disclosure culture that exists now, so there was a lot of “find vuln, post right away for the credits” going on. Couple that with a lot of tool research that was important but also felt very grey-hat, and it was easy to feel like much of the “vulnerability research” community were like a group of scientists working on making cancer airborne “for research purposes”. I admit to having felt that way then, too. Fortunately a lot of that has subsided. The focus on responsible disclosure while still holding companies accountable, the great security research being done by projects like Talos or Project Zero, and the consistent flow of new open-source blue-team tooling has really helped balance the scales (if they were ever unbalanced).
    • tptacek 4y ago
      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.
• Luciatrutth 4y ago
  [dead]
• mikewarot 4y ago
  >The real question to ask is not "can we educate our users to be better at security?" it is "why do we need to educate our users at all?" Great point, but the emphasis on system administration instead of the broken nature of operating systems causes the point to be missed.
• xkcd-sucks 4y ago
  How about "our users can't tell the difference between a DOS attack and us having screwed something up" plus "the people that want to sue us for sucking are at war with the people that want us to look successful to get a promotion for hiring good vendors" etc. /enterprise
• superkuh 4y ago
  Back in 2005 the idea that you shouldn't run every bit of executable code sent to you was drilled into people. Nowadays you can't use a commercial/institutional websites without doing the modern equivalent of opening random email attachments.
  • mb7733 4y ago
    But the client side code in a web-app is run within the browser sandbox, which is not equivalent to running a random exe... Unless you meant something else?
    • superkuh 4y ago
      Speculative execution, sandbox exploits, etc, etc. I thought everyone (myself included) stopped believing in the power of VMs/containers/sandboxes to protect you when all that happened (and kept happening). And it's just getting worse as the JS engine(s) get access to more and more bare metal features and become a true OS in more than just spirit. Thus all the crazy insistence on CA TLS in modern web protocols like HTTP/3 which can't even establish an connection without CA based TLS hand-holding.
      • mb7733 4y ago
        The fact that exploits exist doesn't imply that using sandboxes is equivalent to running untrusted code directly.
  • Gigachad 4y ago
    You also use an OS and browser which is space age technology compared to what they had in 2005. Back then a kid could write an email to install a rootkit on your computer. Now you'd get paid $100k+ if you could work out how to do that. It also used to be common knowledge that if someone has physical access to your device, its game over. Which is something that is becoming rapidly untrue. If I hand my macbook to my friend for a day, I can be quite confident they haven't been able to defeat the boot chain security to replace my kernel with a malware version like you trivially could pre secure boot environments. Another piece of common advice was to not use public wifi because anyone could steal your password or credit card details. Security advice from 2005 really hasn't held up much at all.
• mcqueenjordan 4y ago
  I agreed with much of the article and points made. Maybe I'm missing something (if so, would love to learn!) but I felt that the "Penetrate and Patch" section was a little naive. e.g. > Let me put it to you in different terms: if "Penetrate and Patch" was effective, we would have run out of security bugs in Internet Explorer by now. What has it been? 2 or 3 a month for 10 years? I agree with the point that "Penetrate and Patch" shouldn't be the primary strategy, but the author seems to write it off entirely with a viewpoint like "you should just write software and build systems that don't have security bugs". Well yes, of course that would be nice, but that's not feasible. And some software is much more difficult to get right than other kinds. "Penetrate and Patch" is a useful piece of security in that (a) it can catch what slips through the cracks, (b) it provides a sort of incentive mechanism to get it right in the first place, and (c) it simply isn't possible to build bug-free systems. The author claims that "Penetrate and Patch" finding bugs every month as evidence that it's bad, but isn't it the opposite? You cannot be bug free, so in fact any incremental progress/fixes is in fact good. All that said, I do agree that all of this starts with secure by design. "Penetrate and Patch" isn't a good primary strategy and cannot replace Doing It Right. But I think it complements it well.
  • tptacek 4y ago
    It's not naive so much as it is motivated by enmity for vulnerability research and vulnerability researchers, which was a thing from '98-'05 or so.
    • mcqueenjordan 4y ago
      Ah, got it. Yeah that makes sense, thanks -- I missed how old this was.
  • kgeist 4y ago
    >if "Penetrate and Patch" was effective, we would have run out of security bugs in Internet Explorer by now. What has it been? 2 or 3 a month for 10 years? It also assumes software is static and never changes so it's possible to run out of vulnerabilities to find.
• plaguepilled 4y ago
  I like some of this, but "enumerating badness is a bad idea" is just wrong. Quantifying errors is an important part of tracking progress in software work. Its the same as any other project in life: you track mistakes and address them.
• jojobas 4y ago
  I guess this man's internet heaven is filled by lobotomized users who can only exchange emails with a list of approved correspondents and browse only whitelisted websites. He, of course, gets to approve the lists.
• bryanrasmussen 4y ago
  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.nemid.nu/dk-da/om-nemid/historien_om_nemid https://www.borger.dk/internet-og-sikkerhed/mitid 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.
  • optionalsquid 4y ago
    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.
    • bryanrasmussen 4y ago
      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.
• donatj 4y ago
  > Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? That’s like saying “Why don’t they just design locks that are unpickable?” They’ve been working on that, for a while. But you need to know what you’re protecting against. Anyone who watches The Lock Picking Lawyer knows about the swaths of new locks vulnerable to comb attacks - a simple attack that had been solved for almost a hundred years but somehow major lock manufacturers forgot about. You can’t build something safe without considering potential vulnerabilities, that’s just a frustratingly naive thing to say.
  • albntomat0 4y ago
    To take the strongest form of the author’s argument, his point is that it’s not possible to take a pile of terrible code with no security, and fix all the problems in it. It’s better to architect it in a way that provides security (e.g least privilege everywhere, sandbox, memory safe languages, etc.). I think the author could have phrased it better, in that the best approach is having a good security design, and then taking out all the bugs it couldn’t cover.
• AtlasBarfed 4y ago
  I think this misses two or three big points: 1) Offer solutions not process/procedure: Devs want to make secure systems, but they have VERY LIMITED TIME. Security is always something that is #1 in the bullet points of a presentation of priorities, and always a distant priority in the boots on the ground of features and keeping shit running. What I've noticed is that the security team doesn't want to be responsible for cleanup or doing lots of work or engineering. They want to make presentations for the upper management, pick some enterprise partners to impose on the orgs, and kick back in offices. Most know little about cryptography or major incidents. If a great security practice like "sync ssh keys" or other things that may require a bit of legwork, they don't want to do it. They'd rather load down the devs. They'd rather come in and review the architecture rather than provide drop-in solutions. If something needs customization for interface with SSO or getting credentials, they drop the integration in the devs laps. Who's supposed to be the experts here? The security team should own whatever craptastic enterprisey shit they select, and ALSO be responsible for making it useful to the dev org. The biggest example of this is the desire for "minimum permission". Take AWS for example with its explosive number of permissions, old and new permissions models, and very complicated webs of "do I need this permission" and "what permission does this error message mean I'm missing". And ye gods, the dumb magic numbers in the JSON, but anyway. If the security team wants AWS roles with "minimum viable permission" THEY need to be experts in the permission model and craft these VERY COMPLICATED permission sets FOR THE DEVS. And if the Devs need more, they need to very quickly provide (say < 1/2 day) new permissions in case some new S3 bucket is needed or some new AWS service is needed. But security teams don't want to do such gruntwork. 2) recognize that automated infrastructure is the rule, not the exception, aka the devs are not the enemy It took sooo long for ssh keys to become prevalent in development that people weren't ssh'ing in using passwords. Like, decades. This practice represented a big leap in administration productivity and probably was more secure. And you could automate on top of it in shell scripts, not leave passwords in .history, lots of good things. And the security industry wants you to undo it. Wants TOTP passwords from your phone hand-typed, wants a web page to pop up to gain temporary credentials, pretends you know how long your process will run so those temporary credentials won't expire and if you do, what, you're supposed to manually re-authenticate? Security at my last job wanted an ssh replacement to be used (the enterprise security industry is waging war on ssh/sshd) that if I used it from the command line IT POPPED UP A BROWSER PAGE. And no way to automate this for any task. In general security teams seem obsessed with making devs lives as hard as possible. Are most leaks via dev channels? In my experience the BIG leaks are "County Password Inspector", phishing, disgruntled/angry employees selling access. Well, and credentials checked into github. Most places I've worked at have involved this steadily slide into less and less usability by the devs, at GREAT cost to productivity, for questionable payoff in actual platform security. Meanwhile, no joke, ssl protocols on internal password reset sites were using such poor algorithms that Chrome was refusing to display it. Githubs were open to the public that shouldn't have been. 8-character limit passwords with proscribed character usage. Nuts.
• FatActor 4y ago
  No billion dollar company is anywhere near as glib has the author makes them out to be. Maybe my experience varies, but the European companies I've worked with have strict cybersecurity liability, and they take every aspect of security seriously and do not just pat themselves on the back smugly, as OP portrays. Maybe this was the case in the 90's, but it sure is not the case today. EDIT: I deleted most of my post because I found it was repeated up and down the comments which I am so relieved to see. I kept my post because I want newcomers to hear as many voices in objection to OP's outdated essay as possible.
  • deleted 4y ago
    [deleted]
• Animats 4y ago
  (2005) "Default Deny" was, for a while, called "App Store". However, the app store vendors have done much better at keeping out things for competitive reasons than at keeping out things for security reasons.
• adql 4y ago
  > One of the best ways to get rid of cockroaches in your kitchen is to scatter bread-crumbs under the stove, right? Wrong! That's a dumb idea. One of the best ways to discourage hacking on the Internet is to give the hackers stock options, buy the books they write about their exploits, take classes on "extreme hacking kung fu" and pay them tens of thousands of dollars to do "penetration tests" against your systems, right? Wrong! "Hacking is Cool" is a really dumb idea. That's like, entirely unrelated. Black hats are motivated by monetary gains, not scout badges. The proliferation of internet made "for fun" hackers minority and irrelevant factor (or benefit, as they might actually report a bug instead of sow mayhem) when it comes to security.
  • BulgarianIdiot 4y ago
    Yeah the cockroach analogy is kinda bad. A more apt analogy would be that you can either let rodents help themselves to your food supplies on their own terms, or you can set up traps with a little bit of cheese on them. The traps with little bit of cheese on them here being offering hackers a viable low-stress way to earn income and the respect of society for doing ethical work, which they'll prefer over the high-risk, despite higher-gain, illegal activity they'd contemplate and perpetrate otherwise. Similar mechanics in many ecosystems. Carrot and stick work best together.
    • namaria 4y ago
      I think current practices would be better described in ecosystem terms as: "If a mammal is eating your food, you can adopt a bigger one to prey on them so you share a little bit of food on your own terms instead of compromising the whole community's supply".
  • deleted 4y ago
    [deleted]
• cmdialog 4y ago
  Sorry guy who wrote this article in 2005, hacking is definitely cool.
• scotty79 4y ago
  > Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? How can you engineer a good lock without investing all the ways it can be bypassed by lockpicking lawyer?
• scotty79 4y ago
  > My prediction is that the "Hacking is Cool" dumb idea will be a dead idea in the next 10 years. That didn't age well. In the era of growing corruption in government and business alike hacking becomes important way through which people can actually learn anything about their overlord's shady deals.
• scotty79 4y ago
  > My prediction is that in 10 years users that need education will be out of the high-tech workforce entirely, or will be self-training at home in order to stay competitive in the job market. My guess is that this will extend to knowing not to open weird attachments from strangers. And yet, just yesterday I've seen a TV ad explaining how to not get phished out of your money through your banking app. I think it a running theme in this document that author displays severe lack of understanding how security becomes hard as soon as you let anyone do anything online.
  • blowski 4y ago
    Only last week, I saw someone post on Slack: > I got an email from [CEO] asking me to read a Word doc. I thought it might be a dodgy email so I checked the attachment..."
  • deleted 4y ago
    [deleted]
• scotty79 4y ago
  > #1) Default Permit I guess author of this post is no longer with us because they got heart attack when npm and similar rose to prominence.
  • deleted 4y ago
    [deleted]
  • moffkalast 4y ago
    npm install: "Not to worry, I have a permit." https://i.kym-cdn.com/photos/images/original/001/270/123/1c1.png https://i.kym-cdn.com/photos/images/original/001/270/123/1c1...
• nibbleshifter 4y ago
  That hasn't aged well, at all, lol. The first two points are alright, then it just veers off the rails
  • faeranne 4y ago
    And I'm not even sure about those two. There's a limit to deny first that most end users will gladly override to keep things moving smoothly.
• bartread 4y ago
  > #4) Hacking is Cool As an old I strongly object to the corruption of the terms "hacking" and "hacker" in the diatribe following this heading. I'm a fan of hacker culture, in the old sense, and encourage our developers to adopt a hacker mindset when approaching the problems they're trying to solve. Hacking is cool.
  • tibanne 4y ago
    As an old :D
• fatih-erikli 4y ago
  Penetration testing probably is the dumbest. You will not be sure if it is an honey pot or a real security vulnerability.
• Pengtuzi 4y ago
  Regarding > 6) Action is Better Than Inaction I’m a fan of the > don’t just do something, stand there!
• deafpolygon 4y ago
  > but the second version used what I termed "Artificial Ignorance" - a process whereby you throw away the log entries you know aren't interesting. If there's anything left after you've thrown away the stuff you know isn't interesting, then the leftovers must be interesting. This approach worked amazingly well, and detected a number of very interesting operational conditions and errors that it simply never would have occurred to me to look for. As a sysadmin, I took this approach as well. On the local machine, the server(s) would log normally. But, when I set-up centralized logging, I set-up a list of log entries that wouldn't normally interest me day-to-day. The server would only send to a central logging server things that weren't on this list. What was left were usually problems that I would need to pay attention to and they got fixed faster. The rest of the uninteresting log entries would just be audited from time to time. On the matter of security, every user that logs in on a daily basis gets logged with their IP address. Anytime that a user logged in with a different IP - it would get logged to the central log server and I would be notified. Most of the time, it was harmless.. but there were enough times I would find a compromised account in a sea of normal day-to-day login activity. When your logs are full of normal things in it, it's easy to miss important details.
  • somat 4y ago
    I have the idea of doing spam detection style bayesien analysis on logs. the theory being you feed it your log stream, those are your normal logs, if the log stream start deviating from normal the statistical analysis starts to pop warnings. if it deviants for too long that would become the new normal. At this point I am elbow deep in bayesien email code trying to work out the nuts and bolts of the operation. One important trick is that you need a location aware hash to feed into your statistics engine. A better hash would utilize the structure of log lines, but categorizing logs is big messy yak shaving sort of work. Perhaps a worse more generic hash would be good enough.
    • deafpolygon 4y ago
      Or a list of regex strings?
• EVa5I7bHFq9mnYK 4y ago
  Isn't the author Enumerating Badness in that article?
  • goodpoint 4y ago
    No.
• tsukikage 4y ago
  > A better idea might be to simply quarantine all attachments as they come into the enterprise, delete all the executables outright, and store the few file types you decide are acceptable on a staging server where users can log in with an SSL- enabled browser An odd suggestion in an otherwise relatively uncontroversial article. It implicitly trains your users in a bunch of unpleasant things: * clicking on some URL in an email, typing your password into whatever webpage pops up, downloading the blob it serves you and opening it (after clicking through the browser's "this was downloaded from the internet, are you sure?" warning) is a perfectly normal and legitimate part of the working day * one needs to find ways to obfuscate documents of types that aren't on the IT whitelist so one can send them to one's colleagues so they can do their jobs (and no, the corporate whitelists never capture everything people urgently need to share in order to do their jobs) * since everyone now does that habitually, receiving an automangled email with a link to an attachment which has its actual payload contained in several layers of archive obfuscation wrapper is perfectly normal because that's just what you have to do to share stuff with your colleagues now These could, of course, be mitigated by suitably educating users, but since the practice is advocated in a section about user education never working, that is unlikely to happen.
  • acdha 4y ago
    I think this is a little less bad in context: in 2005 Gmail was a year old. Most people used a dedicated email client app such as Outlook or Mail.app so in your flow it would be far more defensible and his view was focused on corporate users. That makes the first point a little more reasonable: 1. Your desktop application shows a list of attachments in the navigation chrome where a message can't display content. 2. When you click on something in that list, Internet Explorer or Firefox seamlessly logs you into the server using Active Directory. Storing things on a server was also more relevant in the era where space was limited and services like Exchange were famously difficult to scale or customize. If you didn't have good tools to retroactively yank a message out of everyone's inbox when your AV signatures were updated an hour after it arrived, storing it on a server you controlled had a certain practicality. Your second and third points are spot-on, however, and really hit at a key principle too few security teams appreciate: normalization of deviance. This approach fails badly in the real world where IT security says “don't open attachments from people you don't know” and everyone's manager says “oh, it's totally normal to get passworded ZIP files from the HR services subcontractor. Open it, we have a deadline!”. The real lesson here should be defense in depth so your organization's security isn't jeopardized when one person opens the wrong email.
• bluedino 4y ago
  This describes the security industry as a whole. We had a user click an email and get phished. We tried training the users with tools like KnowBe4, banners above the emails that say things like THIS IS AN OUTSIDE EMAIL BE VERY CAREFUL WHEN CLICKING LINKS. Didn't help. The email was a very generic looking "Kindly view the attached invoice" The attached invoice was a PDF file The link went to some suspicious looking domain The page the link brought up was a shoddy impersonation of a OneDrive login In just minutes, the users machine was infected, it emailed itself to all of their Outlook contacts... So this means nothing in this list detected a goddamn thing: Next-generation firewall AI-powered security 'MACHINE LEARNING' 'Prevent lateral spread' enterprise defense suite with threat protection and threat detection capabilities designed to identify and stop attacks AV software that was advertised to 'Flag malicious phishing emails and scam websites' 'Defend against ransomware and other online dangers' 'Block dangerous websites that can steal personal data' the cloud-based filtering service that protects your organization against spam, malware, and other email threats And the company that we pay a huge sum of money to 'delivers threat detection, incident response, and compliance management in one unified platform' didn't make a peep. But, we are up to the standards of quite a few acronyms. It's all a useless shitshow. And plenty of productivity-hurting false flags happen all the time.
  • causi 4y ago
    Have you tried threats and public humiliation? "ATTN ALL employees: Dave Smith ignored security training and was phished into installing malware. He is now fired because he was an idiot."
    • dexterdog 4y ago
      I think there are a number of departments that will help you join Dave in his new-found freedom from employment if you send that.
      • Nevermark 4y ago
        Hmmm. Not if the firing notice was triggered by Dave from a suspicious executable in his email. Although the idea of tightening up security practices by having some sociopathic employee tricking colleagues into publicly firing themselves by malware does make me feel a little ill.
• amelius 4y ago
  My favorite dumbest idea: autorun. But of course, the dumbest idea in computer security is that it always comes last on the budget list.
• gnu8 4y ago
  The clown who wrote this thinks the word hacking means cracking. That automatically negates everything he says. I would not take anything in this article seriously.
• npteljes 4y ago
  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 much faster than setting them up with proper authentication, authorization and access rights. Permit default just works, starts quickly, and works fast. #2: Enumerating badness: you mean, like how we name every single strain of viruses? So now we enumerate computer badness too. #3: Penetrate and patch: very similar to how our laws work, I think. There are people who create injustises, and later the legal code is upgraded to handle that. Again, reactive, like in #1. #4: Hacking is cool - well, other criminals are cool too, like pirates and maffiosos, and so on. People are drawn to power. #5: Educating users: someone has to, doesn't they, if they haven't learnt the thing by themselves? You can't make everyone go away if they are dumb, if you need them. #6: Action is Better Than Inaction: This one, I think, imitates business. There's a lot of ways to make money in business, and being there early is one of them. That said, I really enjoyed the article. Permit by default is especially dumb, it was really funny when mongo installed itself with no password and listen on public IP, default port. And how long it took them to patch that. And how that haven't burned the public goodwill! So maybe these things are not really dumb after all?
  • pixl97 4y ago
    > 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.
• nokcha 4y ago
  > #4 ... "Hacking is Cool" is a really dumb idea. This has aged poorly; nowadays, the most notable attacks are conducted by state actors (e.g., Russia and China) or for-profit criminal groups (e.g., ransomware) rather than lone hackers doing it for fun.
• marcus0x62 4y ago
  > A few years ago I worked on analyzing a website's security posture as part of an E-banking security project. Cool, so a pen test? > One of the best ways to discourage hacking on the Internet is to ... pay them tens of thousands of dollars to do "penetration tests" against your systems, right? Wrong! "Hacking is Cool" is a really dumb idea. ... Most of these are well thought out and still relevant 17 years later. #4 -- particularly the "don't learn offensive security skills as a defender" idea -- was dumb in 2005, and its dumb now. Its also, unsurprisingly, not advice the author has himself followed.