Slashdot Mirror
Java Coders Are Getting Bad Security Advice From Stack Overflow (helpnetsecurity.com)
Slashdot reader Orome1 quotes Help Net Security:
A group of Virginia Tech researchers has analyzed hundreds of posts on Stack Overflow, a popular developer forum/Q&A site, and found that many of the developers who offer answers do not appear to understand the security implications of coding options, showing a lack of cybersecurity training. Another thing they discovered is that, sometimes, the most upvoted posts/answers contain insecure suggestions that introduce security vulnerabilities in software, while correct fixes are less popular and visible simply because they have been offered by users with a lower reputation score...
The researchers concentrated on posts relevant to Java security, from both software engineering and security perspectives, and on posts addressing questions tied to Spring Security, a third-party Java framework that provides authentication, authorization and other security features for enterprise applications... Developers are frustrated when they have to spend too much time figuring out the correct usage of APIs, and often end up choosing completely insecure-but-easy fixes such as using obsolete cryptographic hash functions, disabling cross-site request forgery protection, trusting all certificates in HTTPS verification, or using obsolete communication protocols. "These poor coding practices, if used in production code, will seriously compromise the security of software products," the researchers pointed out.
The researchers blame "the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries." Among their suggested solutions: new developer tools which can recognize security errors and suggest patches.
The researchers concentrated on posts relevant to Java security, from both software engineering and security perspectives, and on posts addressing questions tied to Spring Security, a third-party Java framework that provides authentication, authorization and other security features for enterprise applications... Developers are frustrated when they have to spend too much time figuring out the correct usage of APIs, and often end up choosing completely insecure-but-easy fixes such as using obsolete cryptographic hash functions, disabling cross-site request forgery protection, trusting all certificates in HTTPS verification, or using obsolete communication protocols. "These poor coding practices, if used in production code, will seriously compromise the security of software products," the researchers pointed out.
The researchers blame "the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries." Among their suggested solutions: new developer tools which can recognize security errors and suggest patches.
for bringing us the late-breaking news
You mean advice from people who spend more time hanging out on Stack Exchange and less time actually writing production code is turning out to be less correct than advice from people who talk less and do more? Color me surprised. (Not.)
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Stackoverflow suffers like any other forum : reputation.
Keeping user accounts but making submissions invisible to general users would solve so much on that site.
Just the submissions. Ratings and everything else account-based is only seen by said user, mods and admins.
Won't solve every issue since there are idiots out there blinding trusting other idiots who also learned from other idiots that read the language spec off a blog by another idiot that put together said blog horribly when drunk at 4 in the morning.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
It's ridiculous how much crap is on production servers that can be hacked trivially.
APPS especially. You can hack so many apps by entering emojis! It's so dumb.
People trying to DIY it never learn. But hey, that's not limited to software development.
They keep us actual developers in work by fucking things up so hard. Thanks for my higher rate, friends.
If stack overflow supported nested comments, these "security experts" could post corrections for the insecure code, kinda like how you can correct someone on slashdot. It's pretty stupid to not support nested comments in 2017 (and not the tiny font remarks SO currently uses that make them unsuitable for code).
News flash, heavily simplified programming snippets for the purposes of example and education are probably not suitable for a production environment.
I thought I would try and help people out on Stackoverflow.
I posted some code, but AFAICT I could not just post it in , I had to indent every line by 4 spaces. PITA.
I clarified why a user was getting an error message, and my answer was marked down because some anal type thought it was a comment not an answer, and new users cannot comment, only answer. PITA
A questioner added a comment to ask for an extra feature in my answer, and I could not reply to his comment, because new users cannot comment, only answer.
I gave up.
I suspect many people with valuable knowledge to impart will have done likewise, and left Slackoverflow to the anal badge collectors that appear to rule it.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
Thanks for the chuckle.
Java is [garbage collecting ] very s [gc] e [gc] [gc] cure.
The garbage collection [gc] algorithm [gc] [gc][gc] ensures that [gc] [gc][gc] you never know [gc] [gc][gc] when it will [gc] [gc] [gc] crash and [gc] [gc] can't explot [gc] [gc] [gc] common stack [gc] [gc] [gc] pointer [gc] [gc] [gc] bugs.
Also, since java is slow [gc] [gc] [gc]thats another security feature [gc] [gc].
fast programs crash [gc] [gc] too fast [gc] [gc]. Making exploits [gc] [gc][gc] trivial [gc] [gc].
All operating systems should [gc] [gc] be java based. Try [gc] [gc] [gc] hacking [gc] [gc] [gc] something that [gc] [gc] [gc] takes 3 days to [gc] [gc] [gc][gc] boo java expection error.
[] kinda like how you can correct someone on slashdot.
Typical Slashdot correction: "Have you stopped raping your neighbor's goat?"
When he asks for the YouTube people to come in and film him.
You can hope for good advice but in the long run when it comes to security features, you have to know who you are talking to, what their qualifications are and make sure they're there to support you down the road - which means you are going to pay them. "Gr8CdrGrl427" on Stack Overflow might have an interesting approach as to how to position and code a slider control but taking security advice from them is simply dumb - the worst case is they're making a suggestion that will lead to an exploit they work.
A basic rule of the internet is, don't trust somebody that's helping you for the good of their health.
Mimetics Inc. Twitter
Not really the fault of the language....
Of course the secure 'solutions' should take note that something is deeply wrong with how they go about providing secure options when this happens so much.
People don't do this because they like being insecure, they do it because it's easier.
Disabling CSRF is popular because it's *generally* implemented in a pain-in-the-ass way. Not only in a pain in the ass way, but it seems every five seconds another framework comes up with a slightly different approach to CSRF that isn't any better or worse than the myriad of approaches already. One massive improvement on that front in general would be to disable all that crap if no referrer is set at all, which would solve 99% of the situations where people feel compelled to weaken CSRF protection (non-browser automation).
There are two accepted approaches for TLS if you are note doing things for internet sites: Maintain a convoluted CA setup or if you can't bring yourself to do that, well, disabling it is the only other easy way provided. In my software I tend to provide option of treating TLS software similar to ssh known hosts if CA verification is not an issue, and users are never bothered, until something does go awry.
Using obsolete communication protocols and hashes is generally the consequence of having to interact with data or equipment or older setups. Sure some of it is just people got taught that specific way once upon a time directly addressing low level crypto functions, but a lot is intentional. Of course this is a problem that propagates, new interface to old setup uses old protocol, new thing to talk to new thing, well might as well use old protocol there.
XML is like violence. If it doesn't solve the problem, use more.
Of course not. That goat's ass is so tight...I need to rape it daily.
Coders today are completely lazy, don't give a fuck about doing anything other than writing code and meeting goals. Management didn't tell them to do it? They don't fuckin' do it. I grew up developing web sites and web apps and learned security the hard way ...getting fucking rooted dozens of times! when I started doing development for money I had to make sure someone couldn't just bypass security controls and hack the customer's sites and when they did, you bet your ass i had to FIX IT. It should be obvious to anyone with a fucking pulse that as soon as you put a site online, SOMEONE WILL ATTEMPT TO BREAK INTO IT.
When I got my first professional IT job as a developer, I had to be aware of security on publicly exposed web sites. I had to understand basic concepts such as how requests are handled, how variables are managed, preventing SQL code injections. When I came across vulnerabilities it was my responsibility to communicate that to management and GET THEM FIXED. Oh what you wanted the new company site live thursday? Fuck that, but i'll see what I can do AFTER we fix these other issues. You know something? Not once was I ever told NOT to focus on a major issue when I found one. Those were the "Good old days" - working for a small not-for-profit of all things.
Now, as an IT "Engineer" I manage systems, not code and it's not my place to open my big fucking mouth every time i see something so cringeworthy, i want to just jump out the fucking window. Our fucking developers don't even understand how mother fucking SSL works. I'm NOT MAKING THIS UP. "I don't have time to learn that." they actually say this! Here are a bunch of highly paid professional fucking developers and they don't even know how SSL(ok, TLS now) WORKS ...and here's the kicker, to them, it's not even THEIR FUCKING RESPONSIBILITY to know. Their job is writing code. If two web services can't talk because they don't know how certificate based authentication works, that's not their problem ...to them that's a system problem. How the hell do you think they're going to approach security and vulnerability management?
Is it any surprise then that these very same people don't give one fuck about security, much less even understand the impact of a security vulnerability might be? Hack after fucking hack, all of our personal and private information is being stolen and sold and it's because of people like this. People whose job it is to write code, and whose job it IS NOT to give even a single solitary fuck about security.
Now your typical enterprise may have third party security assessment and penetration testing - which is OK, but most of the time it's testing well-known exploits. The average exposure to vulnerability remediation an enterprise developer gets is putting a ticket into the engineering queue to ask them to modify the load balancer/WAF to add "httponly" and "secure" flags to the fucking cookies. That's when the company starts blowing millions on software and tools to do the work for you, but we all know the buck's gotta stop somewhere. Don't professional enterprise developers have a goddamn duty to be aware of these things and to put the time and effort into avoid such common fucking failures?
Yeah seriously - This is a case where using AC tag is warranted.
It protects the original poster the shame in being labeled a frickin' moron.
Mimetics Inc. Twitter
They hate discussion. Many, many times I've seen a question closed because they were asking a question that was more complicated than mere Q&A. And once an answer is up, "replies" to it are limited to basically Twitter-sized comments. Good luck posting your own answer that corrects people and/or presents a different solution: don't worry, it's not like it will get removed, but you're competing against an accepted answer - which is not the same thing as a "best" or "correct" answer.
Anyone remember programming forums? They're dying because of StackOverflow. But you can find there a community, varied discussions, multiple answers from different viewpoints, and people who are interested more in helping than in getting badges.
If I had a dollar for every time I've had to correct bad advice someone got from StackOverflow, I could take annual vacations to Hawaii.
Is it rape? I donâ(TM)t hear the goat complaining.
I had a friend taking a college course to learn C coding, a supposed good example from class on reading a file was
#include
char c;
while ( (c=getchar() ) != EOF) {
}
for this.
When I've had to make a quick judgment about a programmer's knowledge and competency, I've found that there's one simple question to ask that works wonders:
"What do you think about the Rust programming language?"
Some people will say, "Rust? What's that?". These are typically unskilled people who probably don't know more than elementary JavaScript or PHP. I tend to ignore these people going forward. They're not worth my attention.
Other people will say, "Rust! Rust is fantastic! It's so safe!". These people are typically hype-loving suckers. They've heard of Rust, probably at Hacker News or Stack Overflow, and have bought into the hype about it. They want to come off as "trendy", so they talk about how great Rust is. I tend to ignore these people going forward, too. I don't want to deal with small-minded people like this.
Others will say, "Rust... I tried it. I was not impressed." These people can be respected. They have up-to-date technical knowledge, and they're willing to try new technologies, but they're not blinded by hype. These people are worthy of consideration. One thing to be aware of is that they're neutral about something they should not be neutral about. There are just some things that people should have strong negative feelings for.
Finally, the most intelligent will say, "Rust? Fuck, no. I use C++." These are the people to take seriously. They aren't just neutral about Rust. They actively dislike it. This means that they've probably got a thorough understanding of Rust and its flaws. What's more, they clearly know that C++ is a better alternative, and actively choose to use the best option available. These people get my attention, and I respect what they're saying.
It's really surprising how much insight you can get about somebody from such a short and simple question.
If stack overflow supported nested comments, these "security experts" could post corrections for the insecure code, kinda like how you can correct someone on slashdot. It's pretty stupid to not support nested comments in 2017 (and not the tiny font remarks SO currently uses that make them unsuitable for code).
I've actually studied this at length, and even read a few treatises on the subject. Short answer: nope. Nested comments pretty much suck.
Nested conversations (like those here on slashdot) don't actually make conversations better. They just splinter the conversation into a thousand shards, each of them relatively short, and rarely on topic. They also promote shitty quoting habits and make it difficult to pick up a conversation where you left off without re-reading the whole damn thing.
Flat, linear comments tend to stay on topic, force people to quote properly, and are ordered properly with respect to time.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
What a lot of people don't understand is that Stack Overflow is a very comforting place for autists.
Don't get me wrong, I'm being completely serious about this. I'm not joking about autism and Aspergers, which are very serious disorders that can have a huge impact on somebody's life.
Stack Overflow's community has a rigidity that's nearly unmatched. The only other community that might be as rigid is the Rust programming language community. Both have a strict set of rules that the community must follow, and there's absolutely no flexibility with regards to how these rules are followed. Anyone who deviates from these rules is harshly treated, and in many ways driven out of the community.
This rigid community foundation essentially gives autists a script they can follow. It takes away the difficulties they find with more natural, free-flowing social interaction. All interactions within the Stack Overflow and Rust communities are like following a checklist. They don't have to think about their social interactions; they just follow a template.
Of course, to non-autists this sort of a system seems remarkably strange, and often tyrannical. Non-autists can sometimes find it difficult to understand why people would want to engage in such faux "socializing". But these non-autists fail to realize that those with autism often find great comfort in being subjected to a very strict set of rules, and a sequence of steps they can follow in order to engage in an activity that resembles socializing.
Non-autists shouldn't expect to enjoy engaging in a community like the Stack Overflow community or the Rust community. The structures of such communities have become tailored to work pretty much only for people suffering from autism or Aspergers or some other similar condition.
I'm a veteran of the software industry (3 decades, now) and regularly screen, interview, and hire software engineers -- mostly college grads, some with a few years of experience in the industry. I can tell you with absolute certainty that Java programmers -- those who primarily learned Java in college -- are easily the worst programmers I encounter while hiring. And to date, I haven't hired a single one of them, even though I've talked to and interviewed countless numbers of them.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
so to get this straight people are having trouble understanding a framework that is hard to use and changes faster than the documentation can keep up with it? one of SO's biggest weaknesses is that it keeps obsolete answers around forever, and is hard to use when you have version N+3 of some framework that has changed almost completely since the answers about version N + 1 were posted a year or two ago
the irony is that spring started as a SIMPLIFIED, EASIER java framework to replace heavyweight, difficult stuff like EJB - and now has become what it set out to destroy - so we need a new framework-of-the-weak that is easier to understand to replace spring - the real irony is spring mvc was designed to be a simplified version of struts, but apparently struts hasn't gone away
Not really the fault of the language....
No. It's the fault of the universities that say "This is a great teaching language! We don't have to waste our time on the fundamentals at all! We can just dive right in and start creating classes without understanding niceties like where my variables are actually stored!"
Java is okay for what it is, but if you make it the foundational language for your students, those students will be shite programmers.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
No. Just no. The only thing worse than Java programmers are web developers.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
My neighbour doesn't have a goat you insensitive clod!
... just about all of them are terrible, low quality memory hogs.
QED
Developers absolutely suck at security. This might be for nerds, but how is this news?
If a developer was given root access on an internet-facing server, then within 10 minutes the whole filesystem would be 777, all ports would be wide open, SELinux would be turned off, direct root login from the outside would be enabled, and all processes would run as root or with root permissions.
(Yes, I am a grumpy sysadmin who has had to clean up far too many messes from you clowns. The examples I cited weren't even the most egregious that I've had to deal with after being overruled by management.)
stackoverflow contains shitty advice
Often, it happens because some framework has a convenience method for md5, but not SHA. For example...
String hash = myframework.md5hex(value);
where 'value' can be a String or byte[] compared to... // instantiate a ShaConfigBuilder // set 17 options // instantiate a ShaHashFactory with myShaConfigBuilder // call myShaHashBuilder.parse(myInputStream); // finally get the goddamn hash value // I lied... myShaHashBuilder.parse() returned a ShaHash, and ShaHash has no convenient method to return the hash as a hex string. If you're lucky, it returns it as a BigInteger & you can call its toString(16) method. If you're not, it returns it as a byte[] (or worse, as a base-10 signed value in String form), so you still have to instantiate a new BigInteger.
The point is, md5-related stuff often has nice, easy-to-use no-ceremony convenience methods that return hex strings, while SHA-related stuff is often implemented in a more "modern" (convenience-free) manner that requires a shit-ton of boilerplate tedium to do ANYTHING. Yes, loose-coupling is usually the "right" way to do something... but modern frameworks often take it to tedious extremes.
There's also the fact that Apache HttpClient & Android historically made development on real devices using https to call a web service running on the developer's computer a total nightmare, because HttpClient's certificate list was different than Android's browser cert list, and most factory ROMs made it IMPOSSIBLE to add your own test certs (...growls angrily at Motorola in particular...)
Basically, HttpClient made it SO HARD to do the right thing, nobody DID the right thing.
Things have gotten quite a bit better in recent releases of Android, but this is something that was a never-ending, ongoing pain point for almost 8 years (long after Android itself addressed the problem, there was still the problem of having to support phones with older versions of Android that were stuck with the status quo).
https://www.nbcnews.com/science/space/why-indias-mars-orbiter-mission-cost-less-gravity-movie-n210681
After reading this post, I decided to check out the CERT C Coding Standards and C++ Coding Standards. They want you to create an account to in order to download! Even CERT is clueless on how to make secure programming easily accessible for developers.
Linkies to "a few treatises" ? ( because I think they are very wrong and would like to discuss them, using nested comments ).
Many of the Stackoverflow first answers are very poor, as are many followups from people who don't sanitize their inprts. The problem is aggravated for Java, where error reporting is often very poor and where programmers have been taught with object oriented principles to pay no attention to the rest of the system: it's considered outside the scope of their immediate task.
I do find Stackoverflow useful: there are often extremely useful hooks to start from, and it's well worth thanking the community by following up with my more detailed or robust answers, especially when the published answers did not quite work. That kind of feedback is critical to open source and free software projects.
... ...
If people simply hired web developers, most web hacking shit would be gone over fucking night.
"Web developers" are the Thalidomide babies of the IT world.
I tried starting with Basic, but it made little sense to me. I then tried C, but I couldn't quite grasp it, but I did like the syntax. Then I tried ASM, and it was perfect. Around the age of 8, I gave C another shot, and it suddenly made sense because I understood ASM.
Not really the fault of the language....
No. It's the fault of the universities that say "This is a great teaching language! We don't have to waste our time on the fundamentals at all! We can just dive right in and start creating classes without understanding niceties like where my variables are actually stored!"
How is that relevant to cryptographic hash algorithms, CSRF, certificate validation, or encrypted communication protocols? One could argue the exact opposite: by spending more time on teaching students exactly how variables are stored in memory, you would have less time to teach students about all of the other security issues involved in writing software.
I'm a veteran of the software industry (3 decades, now) and regularly screen, interview, and hire software engineers -- mostly college grads, some with a few years of experience in the industry. I can tell you with absolute certainty that Java programmers -- those who primarily learned Java in college -- are easily the worst programmers I encounter while hiring.
Then you aren't trying to hire software engineers, you're trying to hire programmers.
Yeah, I will confess to not knowing your specific scenario, but I too was faced with a language/library set that had a terrible TLS implementation. I subclassed the plain http class to provide my own tls handling because I know precisely what happens using the default scheme.
This of course drew incredulous response from a security architect that worked on a similar product, saying that I was running a terrible risk by authenticating certificates ssh-style rather than with a CA. I then asked if that concerned him so much, why did his product have a client that allowed user to disable cert validation? He said because users demanded it as soon as they released, and it's the user's fault if that screws them over. I informed him that I didn't provide an option to disable validation, and not one of my users has asked for it. I never could convince him this was a good thing. Note the target market is 99.99% private services not even resolvable by the internet DNS servers. I helped a few of his clients and every last one had hard set it to disable cert validation, and besides I suspect he didn't really understand the underlying way the certificates work, since manually blessed certificates are no more blessed if you use a CA to mark that rather than storing the fingerprints directly.
Too much work in security is about offering a hypothetical possible credibly secure way that no one wants to do, and then offering a feasible approach to get work done so they can blame the users or downstream developers for mistakes. Not enough sentiment of "must make the secure approach also the easy choice".
XML is like violence. If it doesn't solve the problem, use more.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
No. Just no. The only thing worse than Java programmers are web developers.
This is a web site, made by web developers. Criticizing web developers is childish and pointless.
Perhaps offtopic maybe. The scenario here is indicative of general programmer behavior: easy and functional without looking at the consequences.
The annoyance of runtimes and vulnerabilities in those runtimes are a distinct phenomenon. In fact, I'd say that Java's experience is a good example of the problems of shipping language runtime with your app, which can extend to static linking and providing 'appliance' virtual machines or containers. The lazy mindset that infects java app deployment to cause the phenomenon you see,.. those people will crew up *any* target they may have the exact same way (and sadly this happens more and more, with many libraries no longer making the effort to be api compatible version to version, and pointing to dockerhub in general or virtualenv in python or similar strategies as why it doesn't matter to be compatible and have maintenance streams and other such work devs have no interest/patience for if they are allowed to skip it.)
XML is like violence. If it doesn't solve the problem, use more.
You have heard the screaming goat, right? Thatâ(TM)s not pleasure.
Honestly, getting back to the story....a language for which advice is riddled with security holes should scare the crap out of you? Imagine hiring one of these so-called experts. Your business would be in jeopardy because they donâ(TM)t know what they donâ(TM)t know.
Well I never!
Canoncial example of a Stackoverflow exchange:
Answer: Why in the world would you want to do that? Here do this
Answer:
#1 upvote:
#2 upvote:
#4 or #5 most upvoted:
further down:
Stackoverflow is the best for people that sort of know what the answer should be and can separate the wheat from the chaff.
I often point to this on as a good canonical example. https://stackoverflow.com/ques...
"by spending more time on teaching students exactly how variables are stored in memory, you would have less time to teach students about all of the other security issues involved in writing software."
Most of the problems that exist in code are PRECISELY because people don't know where shit is stored, or how it is accessed. Solid fundamentals means solid and informed coding practice. Java is not a solid fundamental for people to start with.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
If poor answers are floating to the top because of reputation, then Stack Overflow has effectively automated argument from authority.
This is not too surprising. Automating fallacy is probably easy. Automating security is likely to be hard. Trust me. I'm an expert on this.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
You could just press edit and fix the answer, the way it's intended
So, I agree with all the haterade at SO and all the things it does wrong and stuff. But let's take a moment of reflection and see if maybe we as a community also did something wrong.
My opinion is that it's a total lack of actually useful documentation. And by that I mean there's almost always documentation, but it's at a level of specificity that makes it totally useless.
By way of analogy, imagine getting into an airplane and there's tons of man pages for each instrument like "The throttle control the amount of forward thrust generated by the engines. It has three auto-throttle modes for speed, trim and power, you can enable those modes by setting the auto-throttle switch to the ON position and adjusting the rotary dial to the desired mode. The power mode cannot be used while the autopilot for level is set."
And so on there's documentation on every little thing but nowhere does it actually explain how the hell to fly a plane.
There are projects whose documentation is exactly like this. They are full of great (and useful) detail about how the parts work but there is no place that explains how the whole project works at a general level and how to get it off the ground.
They're Java coders. Easily replaced.
I tend to rant.
You always get bad advice from Stack Overflow.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
I used to say this a lot; however, I was given an analogy that made me change my mind. When we teach people to drive, we don't make them learn on snow and ice. So why should we make them do that with programming?
So, after reevaluating, I decided we should throw out the "Programming 1 & 2" paradigm that so many schools use. Instead, I would like to see:
Programming 1 (in Java or Python): Focuses on logic, syntax, and simple control statements (if, while, etc.)
Programming 2 (in C or C++): Focuses on what was happening "under the hood" in Programming 1, and starts getting into data structures
Programming 3 (still C or C++): Heavy data structures with an introduction to algorithms. This is where they start learning a bit of architecture, compiler theory, and details on how things work. This is not meant to replace an architecture/compiler/etc. class - but to give the foundation so those classes make sense from day 1.
Yes, this means it adds another full class to an undergraduate program, but it also means that capable, interested students don't get blown out of the water because they don't have the background - or are just bad at classwork. It also makes sure that a student does need to understand the details to obtain their Bachelor's degree.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
Really, I don't know how that god-forsaken site, stackoverflow became the standard go-to for problem solving.
90% of the content on that site are pompous programmers talking down to people and questioning their every motive, or modding newbies down. That site seems to exist to give 99% of most programmers an inferiority complex, more than it does to educate people, or provide quality code.
A standard StackOverflow query tends to go like this:
* User asks a question
Responses:
* instant downvote with no explanation
* mod critique that the question is not properly formatted
* "Why do you want to do that?"
* (wrong answer, but posted really fast)
* "your question is too detailed/not detailed enough"
* "what are you trying to do?"
* pointing out the question has kinda been asked before (but not really)
Here's what I don't get about people harping about using MD5 over SHA or more elaborate encryption... as long as you use a decent salt, and implement system probes, should it really matter? It may be easier to crack MD5 than SHA, but if your authentication code stops brute force attempts, shouldn't it be moot?
By far the hardest part of security is getting companies to care about it.
Well - have you stopped?
And so on there's documentation on every little thing but nowhere does it actually explain how the hell to fly a plane.
There are projects whose documentation is exactly like this. They are full of great (and useful) detail about how the parts work but there is no place that explains how the whole project works at a general level and how to get it off the ground.
That's because the general assumption, in this case, is that the reader already knows how to fly planes in general, and only needs the specifics for this model.
Of course, given the number of coders whose training consisted solely of rote memorization, this assumption is provably wrong. That leads to the sorry state the IT industry is in now, and why I'm very glad I'm training to get my CDL and drive a truck.
Go on, citizen, stamp the vote card. R or D, your choice.
First off, I hate fucking Java. Second, the data may be correct, but the conclusion is out of reality. The reason this is an issue and the up votes go for the easiest not most secure answer, is 1. Human nature, 2. Companies don't give a flying fuck about security. If a "business" leader in a ecom org can't even be bothered to learn a single thing about how a web page even works, then they certainly don't really understand the impact of a few coding side steps and no budget will be allocated DAY TO DAY, to deal with it. After the fact security reviews are doomed to fail, because there is just to much rot after a while.
Sounds like you don't know how it works. The only really problematic part of Java was the browser plugin.
Who's going to pay for training so that developers can recognize bad advice on Stack Overflow, or possibly increase the amount of good advice on Stack Overflow?
Who's going to invest? Who's going to spend the money? And on who's time are they going to be researching better security in code?
What the fuck did you expect?
One big problem SO has is reconciling old questions with "best" answers that might no longer be the best -- or even still RELEVANT.
Suppose that someone posted a message to SO in 2012 asking how to hide the mouse pointer arrow that appears if the user connects a bluetooth or USB mouse to the device when their app (say, an OpenGL ES game) is in the foreground.
Five years ago, the correct and concise answer would have been, "You can't".
Today, the proper answer would be, "You can't do it unless the device has Android N (7.0) or newer AND you target API 24+, in which case here's what you need to do..."
The problem is, if someone posted a new question like this TODAY, some mod looking for easy points would likely flag it within minutes for closure-as-duplicate, EVEN IF the older question's only answer is "you can't". Often, the mods who are the most aggressive about flagging for closure-as-duplicate aren't even subject matter experts in the platform whose questions they're moderating... they're just looking to score easy points for their "Google" skills, and don't BOTHER to actually read anything beyond the search result summaries (let alone consider whether the original questions' answers are still relevant).
This happened on a grand scale for MONTHS after Android Studio moved to Gradle-based projects. People would post questions asking how to do something specific in a Gradle-based Android Studio 2.x project, then get their question swatted down almost instantly (as "duplicate-of-older-question", usually some question about Eclipse or Android Studio 1.0) by users with high reputations, but no discernible expertise in ANDROID development (because the real Android experts KNEW that Gradle was a HUGE change that broke things up, down, left, right, and diagonally).
> Another thing they discovered is that, sometimes, the most upvoted posts/answers contain insecure suggestions that introduce security vulnerabilities in software, while correct fixes are less popular and visible simply because they have been offered by users with a lower reputation score...
So, in essence, qualified answers by low ranking posters -- let's call them ACs -- are not as upvoted as BS from registered users?
Who would imagine that?
When the people signing the checks don't want to pay for security. Try telling the powers that be that the software project, which seems perfectly functional in the demo you just gave them, is still weeks or months away from delivery because we have to implement security. You will see how fast security goes out the window when the money men smell profit and see "first mover" advantage in the marketplace through their tunnel vision.
This is a web site, made by web developers.
A few hardline anti-JavaScript users I've run into are under the impression that Slashdot ought to have been an NNTP site viewed through a news reader, not a website viewed through a web browser. They tolerate web-based discussion forums, though they would prefer a discussion-specific protocol.
With MD5 you can have all the salt of the great oceans and the password would still be easily deducted in an offline attack (which hash you use does not matter in an online attack which is what you describef, heck you could even go with plaintext).
There are two ways to view programming, both of which are very important to understand. There is an abstract model view of programming, and that's what Java could be good at. Except that something like Scheme is ever better at this. This is supposed to be a high level view of what what algorithms actually are as a concept, rather than the implementation details at a machine level.
But you also need the low level view, how things actually get done. If your only model of a program is a bunch of magical black box operators that all take 0 time and space, you can't think well about the problem. Big-Oh notation is meaningless if you don't know what you're measuring. Missing this knowledge is a major hindrance, and yet so many don't realize they have this flaw.
You certainly won't be any good at even basic security without having both an abstract and a concrete model.
There are brute force attempts, and smart brute force attempts. Defending against a brute force attack from your kid sister is easy compared to defedning against a brute force attack from the school bully. The quality of security you have depends upon the value of what you're protecting.
If you don't care about what happens if someone breaks your system, then MD5 is fine and it doesn't hurt much of you ask stack overflow for advice. If your company can be put out of business if your back office data can be cracked or spoofed, then MD5 is foolish to use and any developer relying on hint from stack overflow should be assigned to other less important tasks. If you government can collapse and the country invaded if your data is laid bare then hopefully you're so far beyond stack overflow that you're inventing these security frameworks yourself.
Also, Stackoverflow users a formatting syntax called "markdown". It's the same as Github.
In this case, no, it isn't the same as GitHub. GitHub recognizes several extensions to Markdown that Stack Exchange does not, such as the triple-backtick for code blocks as an alternative to the four-space indent.
Go on, now tell me why that's a bad idea.
People are simply too lazy nowadays. This reminds me of the heady days of BASIC interpreters everywhere.
There's a reason I switched to assembler.
You need more than C. I have a lot of C programmers, and most are terrible at software. That's because they're self-taught EE or science types, they understand the low level details but are extremely lousy at higher level abstractions. Ie, they find it difficult to see the big picture of a large software project, they can't make code that other people can maintain or even decipher, and so forth. Their coding skills seem sto be a mixutre of knowing the syntax and combining with a few key rules of thumb.
That said, those that start with a very high level language usuallly have the same problem just with a different view at it. They still only have a few key rules of thumb, this time applied to the few frameworks or libraries that they understand; their code is so chock full of abstraction layers that no one else understands any of it or is capable of make small modifications safely. They think they understand the big picture only because they've labelled it as "BigPictureInstanceFactory".
Somewhere in there are some key skills that are very rare. If you miss those skills you will be lousy at programming in any language or paradigm.
I think some of the problem is that there is an army of people out there intent on spreading the word that you don't need to learn how to drive on snow and ice, and who will scoff at anyone who does this regularly. They treat driving on snow and ice as akin to climbing Mount Everest. Their solution to anything difficult is to first find the right library or framework that already does it for you. It sort of implicitly assumes that mere mortals don't write these frameworks, in the same way that mere mortals don't climb Mount Everest.
But instead of just saying "that's beyond my abilities" they are teaching others that it's beyond their abilities as well.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
I used to say this a lot; however, I was given an analogy that made me change my mind. When we teach people to drive, we don't make them learn on snow and ice. So why should we make them do that with programming?
In an upper division undergraduate CompSci/CompEng course that I teach, I always tell the students, "spent more time reading code than writing code, being able to read code is more important and valuable to a programmer than being able to write code." I have has several students disagree strongly with that assertion. However, I use the example of learning a foreign language.
I know that programming and human language are different. However, I think that the same principle of learning the language structure (e.g., grammar, syntax, etc.) in order to first master reading holds for both sorts of languages. That is, one does not claim to be proficient in Spanish, French, or Japanese based on being able to speak it but not read it.
I was a terrible programmer for a very long time and what finally made the difference for me was to learn how to really read code. Once I had mastered that, I feel like I improved by leaps and bounds. I really wish that reading code had been emphasized as a core programming skill more when I was in school.
if u just teech C you don't gotta deal with all that faggotry
I was a terrible programmer for a very long time and what finally made the difference for me was to learn how to really read code. Once I had mastered that, I feel like I improved by leaps and bounds
Except that most programmers are terrible and so is their code. Very rarely have I read code written by somebody else that I truly admired. Granted, I'm a bit of a perfectionist when it comes to my coding, but Jesus would it hurt people to write code that doesn't fold like a cheap tent at the first edge case or curveball? Writing code that satisfies the specification exactly and nothing else is the sort that makes others who come after you curse you for leaving them a big mess to clean up. Other tradesman take pride in their craft and workmanship, but so many programmers don't. It's a shame really, but that's what's out there these days.
FTFY
You must live in an area that doesn't get much snow or ice if that made you change your mind. Where I come from (Tennessee), we got a bad snowstorm one or two times a year, and if you didn't want to be trapped in a house with no power, no phone, and no heat, you had better be prepared to drive in snow and ice. Most people I know from back home had their first driving experience—often even before getting their learners' permits and learning to drive on actual streets—by going to some large, wide-open parking lot for some random not-open business and learning how cars behave in the worst conditions.
This has multiple purposes. For one, it makes you appreciate how treacherous driving can be, so you're more careful from then on. For another, you understand exactly how your car behaves in terms of sliding under various amounts of throttle, various amounts of turning, etc. Then, every time you drive a new car in rain, you use those same techniques to quickly learn how much centrifugal force causes the car to start spinning, and you make d**n sure you never come close to exceeding that. People not learning how to drive in snow and ice are the reason we have so many people carelessly spinning their cars around backwards and having wrecks every time there's a light rain in northern California.
Learning C is much the same.
IMO, Java's biggest problem is that object-oriented programming is a terrible way to start learning programming, because it doesn't map very well onto the way humans think about the world. By and large, people think procedurally, not OOPy, not functionally. Yet instructors are forced to introduce concepts like classes and methods really early in Java classes—long before the students actually understand these concepts—because the students have to use classes and methods to do even the most basic things like printing "Hello, world." And unfortunately, C++ has the same problem unless you teach it like C.
I've concluded that schools really should start with a purely procedural language for teaching the basics of programming, not an OO language. Then, move on to data structures—still in a procedural language—for the second class. Finally, teach OOP as the third class. By that point, you can tell them that a class is a glorified struct with syntactic sugar and that methods are glorified function pointers with syntactic sugar. You can also easily explain how to think in an object-oriented fashion and organize code in an object-oriented fashion, because the students have enough grounding in the basics of programming to make that logical leap. And if you do it right, you can also be subtly encouraging OO-like design even within the procedural code, so that objects become natural extensions of things like "static", rather than being a completely foreign concept.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Well, yeah, but you didn't get to that point by not reading their code. You got there by looking at bad code, understanding it, and concluding that it was bad. If you had never seen bad code before, how would you recognize it when you saw it?
Check out my sci-fi/humor trilogy at PatriotsBooks.
That's easily solved. Just introduce dependency injection. Then, even your expert programmers will be unable to understand the big picture, and everyone will be equally confused.
Check out my sci-fi/humor trilogy at PatriotsBooks.
>> ...The researchers concentrated on posts relevant to Java security ...
Java security. Those two words simply do not belong together.
It should be syntaxically forbidden to write them side by side.
aaaaaaa
Ever see how secure a student level C program is?
It's not the language. If you aren't taught basic security concepts you're not going to write secure code regardless of the language. Worse if the language gives you a rocket launcher to blow your own foot off with (like C).
Secure programming isn't something you take one class on to become an expert in, anymore than taking a single course on building a safe makes you capable of building a crack-proof safe. Secure application development is not something you just "pick up". It requires study, resources, and effort. You know, things a number of companies just aren't willing to pay for.
~X~
It depends upon the application.
In an HMAC, PBKDF, etc application, MD5 is still safe practically speaking, but it's easier to avoid raised eyebrows to move on to SHA2 than to explain that. In these scenarios, a has collision isn't going to help.
If you are using the hash as a validation of something else (md5sum of a file, md5 fingerprint of a certificate), that is meaningfully risky, since has collision is the means of breaking it and that is the weakness in the algorithm.
XML is like violence. If it doesn't solve the problem, use more.
In the realm of password cracking a well-salted MD5 hash, it's only 10x quicker to crunch through md5 than an equivalent sha256. If it were a truly random string needing brute force, we are still talking about a million years for a cluster of a thousand nodes with 8x gtx 1080s each to crack a *single* PB-KDF with 1,000 rounds. For a dictionary attack, both methods would fall in short order.
The real weakness in MD5 is in applications that rely on attacker not being able to know a collision, such as md5sums and such.
Of course, no reason to bother to do MD5, easier to just always do SHA2, but in the interest of being accurate about the risk...
XML is like violence. If it doesn't solve the problem, use more.
If your password would fail in an offline attack, it doesn't matter what hash algorithm was used. It's only a 10-fold difference in cracking speed, which for a good password is the difference of 10 million versus a million years, and for a bad password the difference between a minute and 10 minutes.
No reason to use it of course, and it's easier for people to just do SHA2 rather than keep track of whether the meangingful weaknesses (collisions) of md5 matter for your app or not (unless it is unsalted, and unsalted hash of a password *would* be vulnerable to md5's weakness especially, but also opens up the door to rainbow tables regardless of the hash, so not worth much debate there).
XML is like violence. If it doesn't solve the problem, use more.
The difference in bruteforce speed between MD5 and SHA2 is way more than 10-fold, it's 2^128-fold (for the standard SHA2-256) and that is ignoring the known collision attacks in MD5.
If you're worried about offline attacks, you should use bcrypt.
To answer the GP's post: 1) MD5 is vulnerable to certain padding attacks. For instance, Microsoft had a cryptographically signed binary hacked by a dedicated attacker to hijack windows update. Basically, someone created an executable with a virus payload that resolved to the same MD5 signature as the original package. That's BAD. https://www.theregister.co.uk/...
MD5 is vulnerable to what's called a "length extension attack": https://en.wikipedia.org/wiki/...
This means that, in certain cases, you CAN make MD5 secure by doing very special things around how MD5 is used. But you have to know exactly what you're doing and SHA2 is really better anyway. So just use SHA2...
2) SHA1 is has recently had vulnerabilities to the same types of usage. Do not use SHA1 or MD5 for cryptographically signing things. Keep in mind, it's still REALLY difficult to create a SHA1 collision, but engineers at Google did it. https://thehackernews.com/2017...
3) SHA2/3 are still looking secure. It's reasonably expected that if you sign something with SHA2 or SHA3, that someone will not be able to create a different binary/payload as you can with SHA1/MD5.
4) NONE of the above should be used to secure a password/credit card/secure info database. MD5, SHA/1/2/3. For a password database, the worry is someone will hack the DB and extract the information. For this, you should use scrypt or bcrypt (possibly with a salt and/or pepper). This is because the hacker will have the information offline and plenty of time and resources to hack it. In this case, the attacker is trying to brute force the database (by trying every password), with a limited set of (likely) passwords.
For 1-3, you want something that can verify the hash as quickly as possible. For usecase #4, you want an algorithm that takes a long time to verify the hash. This is because a brute force's success rate is dependent on how fast you can try all of the possibilities. If you have 1000 possible passwords and each attempt takes 1ms, then you can try every possible password in 1 second. If each attempt takes 500ms, then this will take 500 seconds.
For this, scrypt/bcrypt has a difficulty algorithm that scales. You basically decide how hard it is to verify a password based on the computational resources at your disposal and how long it should take a user to login. In an application I work on, hash computation actually takes a majority of the login time for the application.
In short:
1) Use Sha2/3 to sign packages, binaries, or transmissions
2) Use scrypt or bcrypt to encrypt data against offline attacks. Pick a difficulty strength as high as you can tolerate.
3) Use MD5 or SHA1 only as a non-cryptographic checksum (did my file get corrupted by a bit flip?--not is someone attacking me)
4) If you use MD5 to sign packages, binaries or transmissions, cracking your encryption will be relatively easy.
5) If you use SHA1 to sign packages, binaries, or transmissions, cracking your encryption will be possible for dedicated hackers.
-=Lothsahn=-
This is not true. SHA2 is only ~15% slower than MD5 at verifying a hash for small data inputs (typical for password bruteforcing). Use bcrypt/scrypt instead.
DO NOT secure a password/cc/sensitive info DB with MD5 or SHA1/2/3.
See this:
http://automationrhapsody.com/...
And my post here:
https://developers.slashdot.or...
-=Lothsahn=-
Dear heavens. MD5 and SHA2 are of equivalent difficulty to use in most cases. Just use SHA2 instead. It's safer and nearly as fast.
/rant
There's like--almost no reason--to implement new code with MD5--unless you're on small embedded platforms that don't support it or something.
-=Lothsahn=-
Funny. I work in a shop of 50 java developers (some of which had other programming backgrounds, many of which did not), and they're all great developers and I'd love to work with any of them in any future job.
But yes, a solid background in assembly or C to understand what the processor is doing really helps.
-=Lothsahn=-
I'm not approving of MD5. I'm saying that if someone uses MD5 out of laziness or ignorance, then they better be on an application or system where there is no need for security. If anyone read that who uses MD5 then they should be shamed into doing something else.
On the other hand, I can barely understand how anyone dumb enough to use MD5 gets put into a position where they get to make critical security choices. Except... startups or other companies who think it's a waste of money to deal with security; if their goal is to get bought out quickly then quality is an unnecessary speedbump in their fantasy.
Any good programmer can reverse engineer how a blackbox is implemented by thinking about the characteristics of the box. Simple load-testing and monitoring resources will tell you almost everything you need to know. Before I even use a library, I first think about the problem I'm trying to solve. Only then can I decide if the black-box is doing what I need done.
I tried starting with Basic, but it made little sense to me. I then tried C, but I couldn't quite grasp it, but I did like the syntax. Then I tried ASM, and it was perfect. Around the age of 8, I gave C another shot, and it suddenly made sense because I understood ASM.
ASM will certainly give you much better insight into what's happening under the hood, so I mostly agree with this.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
This is a web site, made by web developers. Criticizing web developers is childish and pointless.
Speaking of pointless, your statement is orthogonal to the discussion. The fact that this is a website has nothing whatsoever to do with the claim that web developers, are, on the whole, lousy programmers.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
This is a web site, made by web developers. Criticizing web developers is childish and pointless.
Take two: The quality of slashdot does far more to reinforce my point than it does yours.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
One could argue the exact opposite: by spending more time on teaching students exactly how variables are stored in memory, you would have less time to teach students about all of the other security issues involved in writing software.
And yet, as the rate of Java-trained college grads has gone up, security vulnerabilities have skyrocketed. Correlation is not causation, but the graph doesn't do a lot to support your argument, either.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
So like, safe guess is that you have no idea what is CSRF, how cryptographic hash algorithms differ or what it is certificate validation. Hint: they have zero to do with where variables are store, how they are accessed, language you use nor anything else similar.
I'm not Khyber, but I'll answer anyway: Yes, I know what those things are. And though they are important to security, they are not the mechanism by which most security vulnerabilities occur. Ever heard of a buffer overrun? Neither have most Java programmers. All the certificates in the world aren't going to make a damn bit of difference if an attacker can inject code into a running process by taking advantage of a rookie mistake.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
The challenge in the industry is that the most innocuous thing can become a critical security decision.
This is one of the big failings of the status quo, companies have a 'security' team that is somehow on the hook for *everyone else's* code, explictly responsible for a small chunk of formally recognized 'security' related code, while any one left naive about security could botch it for everyone without anyone even realizing the security team should pay attention to it.
XML is like violence. If it doesn't solve the problem, use more.
Here's a benchmark showing hashcat performance, note that md5 is roughly 10 times more than sha-256.
https://gist.github.com/epixoi...
Now maybe you are thinking of cheap single-pass md5 versus some sort of practice incorporating a pb-kdf or similar scheme., but in terms of hash performance, they aren't that far from each other.
Or maybe you are mistaking the hash length for how many guesses are needed. In AES-128 versus AES-256, it is indeed 2**128 more because the unknown key is known to be 256 bit versus 128 bit, but in a crypted password context, the password is the unknown to test against.
Collision attacks only mean something to unsalted password hashes (which are just terrible) and signature verification. It doesn't mean anything for HMAC or HMAC based things like PB-KDF which should be employed if any normal crypto hash is used.
XML is like violence. If it doesn't solve the problem, use more.
At that price, you want quality, too?
There's no time like the present. Well, the past used to be.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
Thanks for the chuckle.
Sure it can be done one week with a single programmer. Ask the marketing manager who is the only one allowed to scope the requirements.
http://saveie6.com/
of course we are talking about properly implemented hashed passwords databases with salts etc and not just a hash of the password!
Why are you implying that we would be talking about a plain hash of a password without any type of salt or constructs (like bcrypt/scrypt)?
In that case, collision attacks should be ignored in this context, since they have no meaning in the face of a salt.
Hashes per second is the metric that matters. If you use MD5 in a PB-KDF of 1000 passes or a SH256 in a PB-KDF of 1000 passes, either way each guess is 1,000 hash calculations, and the key space is identical (the passwords).
XML is like violence. If it doesn't solve the problem, use more.
Security experts can leave comments on answers, and if people like the comments they drift up to be the first comment under the answer. They can leave full answers and point to them in the comments. This isn't a structural SO problem.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Also, Stack Overflow is not intended to facilitate conversations. It's intended to help good answers and comments be in obvious places.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
You are probably not typical of people who start programming as a kid, but I bet you got the fundamentals down better than people start with a higher level language. I started with BASIC in high-school, and in college, most of my software development classes used Pascal (this was the mid-80s). My first professional software development job in 1987 was using C++. I started C++ about 5 years later and have used it for the great majority of time since then. I use Python for side projects, but I still love C++.
The biggest problem I find in other developers is that the code they develop is often way more complex than it needs to be, often to the point where it's almost incomprehensible, even if what it's doing is relatively simple. Often it's a lack of knowledge of the capabilities of stuff like STL, but often it's just, I don't know, not thinking things through, or just not caring. I think laziness is probably the biggest problem in software development.
Defensive programming takes more effort, and it usually takes more thought to write something simple, because you need to design it first instead of just diving in. Creating meaningful and consistent names is probably the most bang-for-the-buck thing you can do when writing software, but very few people do it. Copy-and-paste coding is epidemic, and it causes nothing but pain in the long run. Correcting all these things doesn't always take a whole lot of expertise, but it does require effort and discipline, and those are usually what's lacking.
You are in a maze of twisty little passages, all alike.
Actually, I really wish I could have taught my kids to drive stick. They're good drivers, but we didn't have a manual transmission car when they started driving, so they don't know how. I think learning to drive stick is analogous to learning to program with C. You can do fine without it, but I think you'll do better with it, and have skills that other people will lack.
Of course, it's been close to 30 years since someone who couldn't drive stick asked me to drive something for them, so maybe it's just an obsolete skill.
You are in a maze of twisty little passages, all alike.
Yes sorry about that, don't know what I was thinking about. Sometimes I forget that people keep using short passwords (since I use a password manager I always make sure that my passwords have 256-bit entropy).
That's because the general assumption, in this case, is that the reader already knows how to fly planes in general, and only needs the specifics for this model.
Indeed. And software documentation should assume that the reader already knows how to use a computer in general and only needs the specifics for this particular piece of software.
Take a look at the git book for example. First, it does assume that the reader knows what files are, how files are arranged in a filesystem, how to use a command line. Then it actually explains at high but not abstract level how git actually works. Then it goes through examples of using it. Only last does it provide a reference/glossary type documentation for looking up the detailed syntax of each and every little command.
To be more concrete, not even the most capable and savvy computer person who has never heard of git will be able to understand this sentence:
git fetch
Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories." (although this is there).
If you've never heard of git before, it's just bloody meaningless. No matter how much general knowledge you have, even if you've used CVS and SVN before . . .