Maybe they were right for their time? I'm not arguing that, I just posit that post fact rationalisation about decisions made in the past have to be considered against the evidence in the past.

Things network exploded size-wise and the numbers of participants in the field exploded too.

> the Big Four academic conferences on security

Which ones are those?

Completely agree that offensive research has (for better or for worse) become a mainstay at the major venues.

As a result, we’re continually seeing negative externalities from these disclosures in the form of active exploitation. Unfortunately vendors are often too unskilled or obstinate to properly respond to disclosure from academics.

For their part academics have room to improve as well. Rather than the pendulum swinging back the other way, I anticipate that the majors will eventually have more involved expectations for reducing harm from disclosures, such as by expanding the scope of the “vendor” to other possible mitigating parties, like OS or Firewall vendors.

> Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.

I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).

TBH where you see this kind of thing (mandatory periodic password rotation every month or two) being recommended, it's people not keeping up with even regulators view of good security practice.

Both NIST in the US (https://pages.nist.gov/800-63-FAQ/) and NCSC in the UK (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) have quite decent guidance that doesn't have that kind of requirement.

I’ve been preaching this message for many years now. For example, since password generators basically make keys that can’t be remembered, this has led to the advent of password managers, all protected by a single password, so your single point of failure is now just ONE password, the consequences of which would be that an attacker would have access to all of your passwords.

The n-tries lockout rule is much more effective anyway, as it breaks the brute-force attack vector in most cases. I am not a cybersecurity expert, so perhaps there are cases where high-complexity, long passwords may make a difference.

Not to mention MFA makes most of this moot anyway.

I was going to say passwords too ... but now I think passkeys would be a better candidate for dumbest ideas. For the average user, I expect they will cause no end of confusion.

Password policies are a joke since you use 5 websites and they will have 5 policies.

1. Bank etc will not allow special characters, because that's a "hacking attempt". So Firefox's password generator, for example, won't work. The user works around this by typing in suckmyDICK123!! and his password still never gets hacked because there usually isn't enough bruteforce throughput even with 1000 proxies or you'll just get your account locked forever once someone attempts to log into it 5 times and those 1000 IPs only get between 0.5-3 tries each with today's snakeoil appliances on the network. There's also the fact that most people already know that "bots will try your passwords at superhuman rate" by now. Then there's also the fact that not even one of these password policies stops users from choosing bad passwords. This is simply a case of "responsible" people trying and wasting tons of times to solve reality. These people who claim to know better than you have not even thought this out and have definitely not thought about much at all.

2. For everything that isn't your one or two sensitive things, like the bank, you want to use the same password. For example the 80 games you played for one minute that obnoxiously require making an account (for the bullshit non-game aspects of the game such as in game trading items). Most have custom GUIs too and you can't paste into them. You could use a password manager for these but why bother. You just use the same pass for all of them.

Dear user with password “password11111111111” logging in from a random computer with two password stealers active, from a foreign country, and not willing to use MFA, incident response team will thank you and prepare a warm welcome when you are back to office.

Honestly, this comment shows, that user education does not work.

Minimum length is dumb too because people just append 1 until it fits

on the other hand, to gave us the password game, so there's that.

https://neal.fun/password-game/

> That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.

I'd be very wary of logging into accounts on any computer/phone other than my own.

Based on the type of this rant - all security focused with little thought about usability of systems they're talking about - the author would probably be one of those people that mandate password rotation every week with minimum of 18 characters to "design systems safely by defatult". Oh, and prevent keyboards from working because they can infect computers via USB or something.

(Yes, I'm commenting on the wierd idea about not allowing processes to run without asking - we're now learning from mobile OSes that this isn't practically feasible to build a universally useful OS that drove most of computer growth in the last 30 years).

I don't get how it took until present day for randomly-generated asymmetric keys to become somewhat commonly used on the Web etc in the form of "passkeys" (confusing name btw). Password rotation and other rules never worked. Some sites still require a capital letter, number, and symbol, as if 99% of people aren't going to transform "cheese" -> "Cheese1!".

> people writing passwords down

Which is better, a strong password written down, or better yet stored a secured password manager, or a weak password committed to memory?

As usual, XKCD has something to say about it: https://xkcd.com/936/

We can say that committing crimes is uncool but there’s definitely something appealing about knowing how to do subversive things like pick a lock, hotwire a car, create weapons, or run John the Ripper.

It effectively turns you into a kind of wizard, unconstrained by the rules everyone else believes are there.

Manipulating a remote computer to give yourself access you shouldn't have can be cool if that computer was used in phone scam centers, holding the private data of countless elderly victims. Using that access to disrupt said scam business could be incredibly cool (and funny).

It could be technically illegal, and would fall under vigilante justice. But we're not talking about legality here, we're talking about "cool": vigilantes are usually seen as "cool" especially when done from a sense of personal justice. Again, not talking about legal or societal justice.

It’s that insight that brought forward passkeys, which have elements of SSO and 2FA-only logins. Apple has fully integrated, allowing cloud-sync’d passkeys: on-device for apple devices, 2FA-only if you’ve got an apple device on you. Chrome is also happy to act as a passkey. So’s BitWarden. It can’t be spoofed, can’t be subverted, you choose your provider, and you don’t even have to remember anything because the site can give you the name of the provider you registered with.

I recommend using a well respected browser based password manager, protected by a strong password, and having it generate strong passwords that you never think of memorizing. Web sites that disable that with JavaScript on the password field should be liable for damages with added penalties - I'm looking at you, banks.

meh passwords where a good idea for a long time.

The first 10(20?) years there where no devices without a good keyboard.

The big problem imho was the idea that passwords had to be complicated and long, e.g. a random, alpanumeric, some special chars and at least 12 characters long, while a better solution would have been a few words.

Edit: To be clear I agree with most of your points about passwords, just wanted to point out that we often don't appreciate how much tech changed after the smartphone introduction and that for the environemnt before that (computer/laptops) passwords where a good choice.

I also took issue with this point. One does not become an author without first learning how to read. The usefulness of reading has not diminished once you publish a book.

You must learn how known exploits work to be able to discover unknown exploits. When the known exploits are patched, your knowledge of how they occurred has not diminished. You may not be able to use them anymore, but surely that was not the goal in learning them.

Not necessarily.

There are a lot of script kiddies that don't know a damn thing about what TCP is or what an HTTP request looks like, but know how to use LOIC to take down a site.

It's not about security, it's about control. Modified systems can be used for nefarious purposes, like blocking ads. And Google wouldn't like that.

A friend of mine has trouble running a very important vendor application for his department. It stopped working some time ago, so he opened a ticket with IT. It was so confusing to them that it got to a point that they allowed him to run Microsoft's packet capture on his machine. He followed their instructions, and captured what was going on. Despite the capture, they were unable to get it working, so out of frustration, he sent the capture to me. Even though our laptops are really locked down, as a dev, I get admin on my machine, and I have MSDN, so I downloaded Microsoft's tool, looked over the capture, and discovered that it the application was a client/server implementation ON THE LOCAL MACHINE. The front end was working over networking ports to talk to the back end, which then talked to the vendor's servers. I only knew that I had just undergone a lot of pain with my own development workflow, because the company had started doing "default deny," and it was f*king with my in several ways. Ways that, as you say, I found workarounds for, that they probably aren't aware of. I told him what to tell IT, and how they could whitelist this application, but he's still having problems. Why am I being vague about the details here? It's not because of confidentiality, though that would apply. No, it's because my friend had been "working with IT" for over a year to get to this point, and THIS WAS TWO YEARS AGO, and I've forgotten a lot of the details. So, to say that it will take "3 extra rounds" is a bit of an understatement when IT starts doing "default deny," at least in legacy manufacturing companies.

> Good IT security is invisible and unobtrusive for your users

I wish more and more IT administrators would use seat belt and airbags as models of security: they impose a tiny, minor annoyance in everyday usage of your cars, but their presence is gold when an accident happens.

Instead, most of them consider it normal to prevent you from working in order to hide their ignorance and lack of professionalism.

Good IT security isn't invisible; it's there to prevent people from deploying poorly designed applications that require unfettered open outbound access to the internet. It's there to champion MFA and work with stakeholders from the start of the process to ensure security from the outset.

Mostly, it's there to identify and mitigate risks for the business. Have you considered that all your applications are considered a liability and new ones that deviate from the norm need to be dealt with on a case by case basis?

I believe a "default deny" policy for security infrastructure around workstations is a good idea. When some new tool that uses a new port or whatever comes into use, the hassle of getting IT to change the security profile is far less expensive then leaking the contents of any particular workstation.

That being said, in my opinion, application servers and other public facing infrastructure should definitely be working under a "default deny" policy. I'm having trouble thinking of situations where this wouldn't be the case.

Company IT exists to serve the company. It should not cost more than it benefits.

There’s a balancing act. On the one hand, you don’t want a one-week turnaround to open a port; on the other you don’t want people running webservers on their company desktops with proprietary plans coincidentally sitting on them.

That's because IT security reports to the C level, and their KPI's are concerned with security and vulnerabilities, but not the performance or effectiveness of the personnel.

So every time, if there is a choice, security will be prioritized at the cost of personnel performance / effectiveness. And this is how big corporations become less and less effective to the point where the average employee rarely has a productive day.

> Meanwhile, the rest of the company is super annoyed because nothing ever works without three extra rounds with the IT department

This is such an uninformed and ignorant opinion.

1. Permission concepts don't always involve IT. In fact, they can be designed by IT without ever involving IT again - such is the case in our company.

2. The privacy department sleeps much better knowing that GDPR violations require an extra u careful action, than being a default. Management sleeps better knowing that confidential projects need to be shared, instead of forgetting to deny access for everybody first. Compliance sleeps better because all of the above. And users know that data they create is private until explicitly shared.

3. Good IT security is not invisible. Entering a password is a visible step. Approving MFA requests is a visible step. Granting access to resources is a visible step. Teaching users how to identify spam and phishing is a visible step. Or teaching them about good passwords.

> Meanwhile, the rest of the company is super annoyed because nothing ever works

Who even cares if they're annoyed. The IT security gets to sleep at night, but the entire corporation might be operating illegally because they can't file the important compliance report because somebody fiddled with the firewall rules again.

There is so much more to enterprise security than IT security. Sometimes you don't open a port because "it's the right thing to do" as identified by some process. Sometimes you do it because the alternative RIGHT NOW is failing an audit.

> Good IT security is invisible and unobtrusive for your users, like magic

Why is this a standard for "good" IT security but not any other security domain? Would you say good airport security must be invisible and magic? Are you troubled by having to use a keycard or fingerprint to enter secure areas of a building?

Security is always a balance between usability and safety. Expecting the user to be completely unaffected through some magic is unrealistic.

That’s what I gave my firewall, all out traffic is default deny, then as the screaming began, I started opening the necessary ports to designated IPs here and there. Now the screaming is not so frequent. A minor hassle… the tricky one is the DNS over HTTPS… that is a whack-a-mole if I ever saw one.

"If you're able to do your job, security/it/infosec/etc isn't doing theirs." Perhaps necessary at times, but true all too often.

the article is great, but reading some of the anti security comments are really triggering for me.

good IT security is invisible, allows me to do everything I need, protects us from every threat, costs nothing, and scales to every possible technology the business buys. /s

> These people in my experience ignore the difficulties that a purely security-oriented approach imposes on users

Your scale analogy is probably more approachable, but I'm a little more combative. I usually start out my arguments with security weenies with something along the lines of "the most secure thing would be to close up shop tomorrow, but we're probably not going to get sign-off on that." After we've had a little chuckle at that, we can discuss the compromise we're going to make.

I've also had some luck with changing the default position on them by asserting that if they tell me no, then I'll just do it without them, and it'll have whatever security I happen to give it. I can always find a way, but they're welcome to guide me to something secure. I try to avoid that though, because it tends to create animosity.

Steelmanning for a moment: I think what the author is trying to address is overly targeted "patches" to security vulnerabilities which fail to address the faulty design practices which led to the vulnerabilities. An example might be "fixing" cross-site scripting vulnerabilities in a web application by blocking requests containing keywords like "script" or "onclick".

I agree, an example that if you say something dumb with enough confidence a lot of people will think it's smart.

It's also outright stupid. For example, from the section about hacking:

> "Timid people could become criminals."

This fully misunderstands hacking, criminality, and human nature, in that criminals go where the money is, you don't need to be a Big Burly Wrestler to point a gun at someone and get all of their money at the nearest ATM, and you don't need to be Snerd The Nerd to Know Computers. It's a mix of idiocy straight out of the stupidest 1980s comedy films.

Also:

> "Remote computing freed criminals from the historic requirement of proximity to their crimes."

This is so blatantly stupid it barely bears refutation. What does this idiot think mail enables? We have Spanish Prisoner scams going back centuries, and that's the same scam as the one the 419 mugus are running.

Plus:

> Anonymity and freedom from personal victim confrontation increased the emotional ease of crime, i.e., the victim was only an inanimate computer, not a real person or enterprise.

Yeah, criminals will defraud you (or, you know, beat the shit out of you and threaten to kill you if you don't empty your bank accounts) just as easily if they can see your great, big round face. It doesn't matter. They're criminals.

Finally, this:

> Your software and systems should be secure by design and should have been designed with flaw-handling in mind.

"Just do it completely right the first time, idiot!" fails to be an actionable plan.

though, frequent updates mainly serve to hide unfit engineering practices and encourage unfit products.

the world is not static, but most things have patterns that need to be identified and handled, which takes time that you don't have if you sprint from quick-fix to quick-fix of your mvp.

There's definitely a few worthwhile nuggets in there, but at least half of this reads like a cringey tirade you'd overhear at the tail end of the company holiday party from the toasted new helpdesk intern. I'm surprised to see it from a subject matter expert, that he kept it on his website for 20 years, and also that it was so heavily upvoted.

I really didn't think "write secure software" would be controversial, but here we are. How is the nihilist defeatism going? I'll get back to you after I clean up the fallout from having my data leaked yet again this week.

*Translation: If we didn't just pile on dependencies upon dependencies, everything would be secure from the start.

Come on. The piss-poor security situation might have something to do with the fact that the vast majority of software is built upon dependencies the authors didn't even look at...

Making quality software seems to be a lost art now.

[flagged]

> This is a mostly terrible 19-year old list.

This is an excellent list that is two decades over due, for some

> software and systems should be secure by design

That should be obvious. But nobody gets rich except by adding features, so this needs to be said over and over again

> This will never happen, so we need to utilize the find and patch technique,

Oh my giddy GAD! It is up to *us* to make this happen. Us. The find and patch technique does not work. Secure by design does work. The article had some good examples

> Most applications/systems are updated frequently, which means new vulnerabilities will be introduced.

That is only true when we are not allowed to do our jobs. When we are able to act like responsible professionals we can build secure software.

The flaw in the professional approach is how to get over the fact that features sell now, for cash, and building securely adds (a small amount of) cost for no visual benefit

I do not have a magic wand for that one. But we could look to the practices of civil engineers. Bridges do collapse, but they are not as unreliable as software

A major dumb is that security people think breaking in is the end of the world. For vast majority of users it's not, and it's a balance between usability and security.

I know it's rather easy to break through a glass window, but I still prefer to see outside. I know I could faff with multiple locks for my bike, but I rather accept some risk for it to be stolen for the convenience.

If there's something I really don't want to risk stolen, I can take it into a bank's vault. But I don't want to live in a vault.

It's very easy for a big organisation with a leadership that needs to show it is doing something to pass down a mandate that relies on throwing money at the problem for little tangible benefit. "Everything needs to be pen tested" is the sort of thing that sounds like the right thing to do if you don't understand the problem space; it's exactly as wrong as using lines of code as a productivity metric.

All it does is to say, very expensively, "there are no obvious vulnerabilities". If it even manages that. What you want to say is "there are obviously no vulnerabilities" but if you're having to strap that onto a pre-existing bucket of bugs then it's a complete rebuild. And nobody has time for that when there's an angry exec breathing down your neck asking why the product keeps getting hacked.

The fundamental problem is the feature factory model of software development. Treating software design and engineering as a cost to be minimised means that anything in the way of getting New Shiny Feature out of the door is Bad. And that approach, where you separate product design from software implementation, where you control what happens in the organisation with budgetary controls and the software delivery organisation is treated as subordinate because it is framed as pure cost, drives the behaviour you see.

At the risk of stating the obvious, the word "hacker" has (at least) two distinct meanings. The article talks about people who try to break into systems, and Hacker News is about people who like to hack away at their keyboard to program interesting things.

The world might have been a better place if we used the terms "cracker" and "tinkerer" instead.

[flagged]

From Britannia: https://www.britannica.com/topic/hacker

> Indeed, the first recorded use of the word hacker in print appeared in a 1963 article in MIT’s The Tech detailing how hackers managed to illegally access the university’s telephone network.

I get what you’re saying, but I think we’re tilting at windmills. If “hacker” has a connotation of “breaking in” for 61 years now, then the descriptivist answer is to let it be.

> Why the security theater industry has appropriated "hacking" to mean accessing other people's systems without authorization, I don't know.

A lot of early remote access was done by hackers. Same with exploiting vulnerabilities.

One of my favorite is the Robin Hood worm: https://users.cs.utah.edu/~elb/folklore/xerox.txt

TL;DR: Engineers from Motorola exploited a vulnerability illustrate it, and they did so in a humorous way. Within the tribe of hackers, this is pretty normal, but the only difference between that and stealing everything once the vulnerability has been exploited is intent.

Normies only hear about the ones where people steal things. They don't care about the funny kind.

If owners are able to tweak or upgrade the machine themselves, it will hurt sales of next year’s model. If “hacking” helped corporations make money they would spend billions promoting it. The old meaning of hacking has been replaced with “maker.”

[flagged]

Yeah, we're not gonna convince people in other countries that hacking is uncool. Better to have the advantage.

From the 2015 submission:

> Perhaps another 10 years from now, rogue AI will be the primary opponent, making the pro hackers of today look like the script kiddies.

Step on it OpenAI, you've only got 1 year left ;)

This true in a very small part of our business

Most of us are not involved in a "land grab", in that metaphorical world most of us are past "homesteading " and are paving roads and I filling infrastructure

Even small companies should take care when building infrastructure

"Go fast and break things" is, was, an irresponsible bad idea. It made Zuck rich, but that same hubris and arrogance is bringing down the things he created

> You will probably spent some time "teaching" them first

SELinux works well out of the box in RHEL and its derivatives since many years. You comment shows, you did not actually try it.

> fight with them every time you install something or make other changes in your system

If you install anything that does not take permissions into account, it will break. Try running nginx with nginx.conf permissions set to 000, you will not be surprised, it does not work.

True security can only come from understanding how your system works. Otherwise, you're just inventing a religion, and doing everything on faith. "We're fine, we update our dependencies." Except you have no idea what's in those dependencies, or how they work. This is, apparently, a controversial opinion now.

It's a little anecdotal as nobody was really writing history down at that point but it feels about the right timing.

The first time the FTP server I ran got broken into was about then, it was a shock as why would some a-hole want to do that? I wasn't aware until one of my users tipped me off a couple of days after the breach. They were sharing warez rather than porn at least, having the bandwidth to download even crappy postage stamp 8 bit color videos back then would take you hours.

When this happened I built the company's first router a few days later and put everything behind it. Before that all the machines that needed Internet access would turn on TCP/IP and we'd give them a static IP from the public IP range we'd secured. Our pipe was only 56k so if you needed it you had to have a really good reason. No firewall on the machines. Crazy, right?

Very different times for sure.

[flagged]

I also think that capability based security is a good idea, and that proxy capabilities should also be possible. (This would include all I/O, including measuring time.)

But, how the UI is working with capability based security, is a separate issue (although I have some ideas).

(Furthermore, I also think that capability based security with proxy capabilities can solve some other problems as well (if the system is designed well), including some that are not directly related to security features. It can be used if you want to use programs to do some things that it was not directly designed to do; e.g. if a program is designed to receive audio directly from a microphone, you can instead add special effects in between by using other programs before a program receives the audio data, or use a file on the computer instead (which can be useful in case you do not have a microphone), etc. It can also be used for testing; e.g. to test that a program works correctly on February 29 even if the current date is not February 29, or if the program does have such a bug, to bypass it by telling that program (and only that program) that the date is not February 29; and you can make fault simulations, etc.)

I think commenting short summaries like this is not beneficial on HN. It destroys all nuance, squashes depth out of the discussion, and invites people to comment solely on the subtitles of a full article. That's not the kind of discussion I would like HN to degrade into — if I wanted that, I'd go to Buzzfeed. Instead I hope everyone takes the time to read the article, or at least some of the article, before commenting. Short tldrs don't facilitate that.

xdg-desktop-portal was created to allow applications running in a sandbox to access system resources. Nowadays, more and more, regular applications have to pass through this piece of crap to do their usual work, one which by design was never intended for them, but for flatpakked applications.

Oh the joy of going through the bluetooth pairing process for my controller, or physically getting up and connecting a physical wire to it, only for the system to wait until I'm in the game and touch the controller and immediately the game hangs because a pop up appears asking me if i want to give permission to my damn controller to control stuff. Or having to manually reposition my windows every single time, because a window knowing where it is is somehow "insecure"

I'm the one putting the software on there and deciding what to run. If I run it, then it's because I wanted the application to do what it does. If someone else is in the position of running software on my machine, they're already on the other side of the airtight hatchway. They can already give themselves the permissions they need. They can just click yes on any pop up that appears. Yes, the applications should be considered safe. Because the OS cannot possibly make any informed assumptions about what's legitimate and what's malicious.

To me it feels like I can't do certain stuff on my PC because someone else might misuse something on theirs. How is that my problem?

It does work, but user training is something that- whether for security or otherwise- is a continuous process. New hires. Training on new technologies. New operating models. etc etc etc...

IT is not static; there is no such thing as a problem that the entire field solves at once, and is forever afterward gone.

When you're training an athlete, you teach them about fitness and diet, which underpins their other skills. And you keep teaching and updating that training, even though "being fit" is ancillary to their actual job (i.e. playing football, gymnastics, etc). Pro athletes have full-time trainers, even though a layman might think, "well haven't they learned how to keep themselves fit by now?"

Agreed, eyebrows were elevated at this point in the article. If you want to build a good lock, you definitely want to consult the lock picking lawyer. And its not just a poor choice of title either:

> teaching yourself a bunch of exploits and how to use them means you're investing your time in learning a bunch of tools and techniques that are going to go stale as soon as everyone has patched that particular hole

Ah yes, I too remember when buffer overflows, xss and sql injections became stale when the world learned about them and they were removed from all code bases, never to be seen again.

> Remote computing freed criminals from the historic requirement of proximity to their crimes. Anonymity and freedom from personal victim confrontation increased the emotional ease of crime […] hacking is a social problem. It's not a technology problem, at all. "Timid people could become criminals."

Like any white collar crime then? Anyway, there’s some truth in this, but the analysis is completely off. Remote hacking has lower risk, is easier to conceal, and you can mount many automated attacks in a short period of time. Also, feelings of guilt are often tamed by the victim being an (often rich) organization. Nobody would glorify, justify or brag about deploying ransomware on some grandma. Those crimes happen, but you won’t find them on tech blogs.

That. Also not educating users is a bad idea but it also becomes quite clear that the article was written in 2005 where the IT/security landscape was a much different one.

You do not have to be able to build actual sql injection yourself in order to have properly secured queries. Same with xss injection. Having rough ideas about attacks is probably necessary, but beyond that you primary need the discipline and correct frameworks that wont facilitate you to shoot yourself in the foot.

I don't think the argument is that dumb. For a start there's a difference between white hack hackers and dark hat hackers. Then here he's talking specifically about people who do pentesting known exploits on broken systems.

Think about it this way: do you think Theo Deraadt (from OpenBSD and OpenSSH fame) spends his time trying to see if Acme corp is vulnerable to OpenSSH exploit x.y.z, which has been patched 3 months ago?

I don't care about attacking systems: it is of very little interest to me. I've done it in the past: it's all too easy because we live in a mediocre work full of insecure crap. However I love spending some time making life harder for dark hat hackers.

We know what creates exploits and yet people everywhere are going to repeat the same mistakes over and over again.

My favorite example is Bruce Schneier writing, when Unicode came out, that "Unicode is too complex to ever be secure". That is the mindset we need. But it didn't stop people using Unicode in places where we should never have used it, like in domain names for examples. Then when you test an homoglyphic attack on IDN, it's not "cool". It's lame. It's pathetic. Of course you can do homglyphic attacks and trick people: an actual security expert (not a pentester testing known exploits on broken configs) warned about that 30 years ago.

There's nothing to "understand" by abusing such exploit yourself besides "people who don't understand security have taken stupid decisions".

OpenBSD and OpenSSH are among the most secure software ever written (even if OpenSSH had a few issues lately). I don't think Theo Deraadt spends his time pentesting so that he can be able to then write secure software.

What strikes me the most is the mediocrity of most exploits. Exploits that, had the software been written with the mindset of the person who wrote TFA, would for the most part not have been possible.

He is spot on when he says that default permit and enumerate badness are dumb ideas. I think it's worth trying to understand what he means when he says "hacking is not cool".

[flagged]

[flagged]