Software engineering is fairly similar to structural engineering. Just as an architect does not truly understand how to create an indestructible building without first learning how buildings are destroyed, you can't possibly hope to create a secure software system without understanding how software is broken.
Earthquakes don't adapt their attack strategies as well as hackers. Learning to hack will help you harden against the lamest attacks of five years ago. Every single buffer-overflow can be fixed by simply keeping up on patches. Every SQL Injection vulnerability can be fixed by using a proper database access layer.
I find it much more effective to first apply basic coding standards based on OWASP, then to think of every web page from a request-response perspective instead of from a user perspective. 90% of the stupid security coding I've seen came from somebody who never considered that an attacker doesn't have to be using a standard web browser. Once you get over that hump, there is no value in learning all of the script-kiddie tricks.
I also find that security professionals often lack perspective. I once had a security guy go into great detail showing me how a page was vulnerable to cross-site request forgery and replay attacks. I told him "It's a catalog page, I don't care who reads it. It's URL-parameterized so that my customers can email links to each other. In other words, I'm counting on CSRF for sales.". The funny part is that if I had used URL rewriting instead of a query string parameter, he wouldn't have even known the feature existed.
I am a firm believer that security belongs in the application team. Engaging an outside expert tends to send the message that it's somebody else's responsibility to do security. In reality, security is everyone's problem.
That's easy to game. IT is generally the "say no" department, so if you need to have someone talk you up to the boss, simply turn off the FaceBook filter for someone while you're working on a ticket. Or maybe do shoddy work on the PITA users because their feedback is going to be ignored anyways so you have extra time to bring coffee to one of the more respected users. There are a ton of things you can do to elevate the metric without actually doing better work. On the other side of the coin, being rude is a near guarantee that you will get horrible feedback. I'm not saying it's OK to be rude to people, but I am saying that politeness is over-represented in satisfaction metrics to the point where incompetent but good-natured people will never get poor feedback, even if they never solve a single problem.
So, you do a half-assed job, but remove their firewall restrictions and install a few games while you are at it. Instant satisfaction ratings while simultaneous not getting work done. As soon as a whiff of a mediocre satisfaction report comes in, the hammer comes down and everybody realizes that as long as they keep filling in "excellent" on the surveys, the party can continue.
All help desk metrics are useless. The best guy should be assigned the hardest cases, but that pushes his numbers down. Level three gets all of the impossible cases and is the final word when the answer is "no", so they get lower satisfaction ratings. Cheery chick that closes 20% of her calls, but is very pleasant to listen to and is very nice while transferring 80% of her calls to level two gets stellar ratings. The grumpy guy who has zero social skills, but has memorized every support resolution in the database and gets people off the phone with their problem solved buy saying "moron" and hanging up on them is the biggest productivity booster in the entire company, but he makes people feel bad about themselves, so he gets fired.
I got talked to one time for having a ticket open for two years. The ticket was for a real bug the really did negatively impact the user. However, it was never a high enough impact to get a manager to sign off on the change control to get it implemented. My boss coerced me into closing the ticket with a nebulous resolution because his manager didn't like what it did to the numbers. In summary, the people who review and judge the numbers asked for the numbers to be fudged so that they would be happy with the numbers when they reviewed them.
This is too easy to game. I used to work at a training center where our most important metric was post-class evaluations. One day, some brainiac decided that merit raises would be decided solely on evaluation scores. From that day on, nobody got under 95% on evaluations and the difference between the best and the worst was statistically insignificant. If you want honest metrics, you have to collect them for their own sake and not actually use them. As soon as you tie incentives and punishments to them, the people being measured start spending all of their waking hours figuring out how to artificially inflate them. The only good metric is a metric that you want employees to game, like "Units Produced That Pass QC per Hour".
If you're wondering how we did it, we used to do the following:
1. Force students to hand the evaluation to us after they fill them out. The easiest way to do this was to trade evaluations for certificates. Simply tell them that you have to do it this way because their feedback is important and it's the only way to ensure that everyone turns in an evaluation.
2. Say the following as you pass out evaluations; "Your feedback is very important to us. We don't simply want to know that we aren't doing an excellent job, we need to know how to remedy our shortcomings. So, please, if you give me any score below the highest score, include a detailed comment so I know exactly what I need to improve." 90% of students would give you perfect scores simply because they didn't want to write any comments.
3. Use the specific wording on the evaluation during class. For example, if one of the evaluation ratings is "Used Analogies Effectively", then make sure to lead off any analogy with the phrase "I good analogy for this might be...".
4. Be a pretty girl and flirt. Seriously, our worst instructor got the highest evaluation scores. However, her scores had a strong positive correlation to the percentage of male students in her classes. I did the math once, the correlation was at least r=0.8. Lucky for her IT training students are predominantly male.
If you are ever in a training class and hear any of these things, give the instructor down the middle scores for being an evaluation-whore.
Yup. However, having just had one of my applications scanned by one of these tools, I can say that if you fail one of these scans, you're app is worse than it says it is. I got a mostly clean bill of health, but the feedback I got was ridiculous. For example, the security department says that all pages of all publicly facing web apps should use SSL. Fine. But, the scan dinged me for caching pages delivery by SSL. So, do I violate the mandate to use SSL on trivial data? Do I violate the common sense approach of adding cache-control directives to static trivial elements like company logos? All the scan did for me is make me spend 4 hours justifying why the scan was worthless.
No, he's saying that it's expensive to say exactly what he wants, and that offsets all of the savings. At the end of the day, it's the thinking that's expensive not the typing. If you move the typing to India, but don't move the thinking, then you've hired a typist instead of a programmer.
Right, because there are no sociopaths working in engineering. No, weapons design themselves. So do fighter jets! Wow, thank you idealistic nerd!.
Yes, one counterexample proves a correlation invalid. Are you a manager, or just a sociopath?
Get over yourself, just because you can't work with people doesn't mean those that do are sociopaths.
It's well documented that people with sociopathic personality traits succeed in management. Also, I don't need to "get over myself", I do work with people. I've been successful in both training and management.
We do make more money than you and don't need to learn new languages and processors and OSes at our own expense every six months.
So, in a thread about engineering education, you bring up learning languages and OSes and paying for your own training. You do know that engineers and programmers are different set of people, right?
Funny thing... 6000 freshmen are admitted to my Alma mater's School of Engineering every year and fewer than 1000 graduate every year. The other 5000 simply can't do the work.
That sounds like a failure to teach.
Some things are unteachable. Some things are so hard to teach that it's easier to simply select students that exhibit the behavior instead of trying to instill the behavior in students that don't exhibit it (especially if the job market only needs as many as, or fewer than, there are natural candidates). Engineering is the second. It's hard to let go of the physical world and replace it with mathematical abstractions. Some people get it and some people don't. Those that don't can compensate for a while by learning how to do every problem form, but they'll eventually get tired and choose to do something else. Those that can do it find engineering fun and rewarding. A good teacher might be able to help a few extra percent "get it", but any more isn't really realistic.
Engineering isn't the only discipline that works this way. There are studies that show that bad programmers can never be turned into good programmers. You can't make someone a great musician through practice alone. Some people will never be good at sports.
Just because somebody plops down $170,000 to go to Cornell and gets accepted doesn't mean that the university must spend as much time with the student as necessary to make them succeed. Good engineering schools don't guarantee that all entering students will come out the other side qualified, they guarantee that all the student that do come out the other side are qualified.
Blaming the teachers for the dropout rate is similar to the "no child left behind" mentality. Asking teachers to spend their time and effort on those with the least chance of success while ignoring those with a greater chance of success will produce a lot of mediocre results. Asking teachers to give everyone the same opportunity to be their best will produce some successes and some failures. The ratio of successes to failures will be primarily determined by the students' potential, not the teachers skill. MIT has a graduation rate over 90% because they only admit the brightest (and most motivated) in the country, not because they have the best faculty.
You seem to have gone to a bad university. I have an engineering bachelors degree and my freshmen classes were full of practical problems, fun labs, and information that was obviously going to be the foundation of everything we were going to learn. Funny thing... 6000 freshmen are admitted to my Alma mater's School of Engineering every year and fewer than 1000 graduate every year. The other 5000 simply can't do the work. It's not a matter of the faculty not teaching them well enough, the students simply decide that engineering is too much work and there are others ways to make a living. I don't blame them, an MBA and a sociopathic attitude will get you a lot more money for a lot less effort than an engineering degree will.
Which is why, if the US is blatently attacked, they will respond with troops and bombs instead of cyber retaliation. That's one of the points of making the Internet a 5th domain. I would envision a typical response to be either cutting off the Internet connections from an attacking country (by physically destroying the cables with air strikes), or pinpointing the location of the attackers and turning them into red mist.
I think it's screwed up that foreign workers have to pay into a retirement system they will never see a nickle from.
Social Security isn't a retirement system. It's a social safety net funded by a specific tax. A quarter of the recipients of Social Security benefits aren't of retirement age, guess where their money comes from? The biggest problem with Social Security is that many people see it as a system that holds on to your money and gives it back to you when you retire. Foreign workers living here benefit from the fact that we don't simply cast out those that cannot support themselves and make them fend for themselves.
120Hz doesn't fix the major problem; expensive glasses. The interleaved method is used to support passive glasses. Alternating between full-resolution right and left eye images will always require active glasses.
It happens enough to require some concrete explanation other than ignorance. There could be a few possible explanations, from the customer service department demanding to know user's passwords in order to help customers more quickly, to someone in IT deciding storing clear-text password will allow a simpler shift from one back-end to another at some time in the future. Since these reduce a small amount of pain on the organization and the loss of passwords brings no pain (except to their customers), the insecure method wins the trade-off.
BTW, I am currently in the middle of a back-end migration where having hashed passwords is causing me some pain. My life would be much easier if these passwords were stored in clear text. I realize that this is simply the cost of reasonable security, but some people might see it differently, especially if they don't value their customers at all.
They wouldn't be too bad. The ability to buy insurance the day before you need it implies that the need can be predicted very accurately. So, if you were due to make a claim tomorrow, your premium would suddenly go up based on your elevated risk level. If you weren't due to make a claim tomorrow, your insurance would still be cheap; possibly nearly free since it the insured event is highly predictable and you aren't due. In the most extreme variation of this theme, insurance would cost about the same as simply paying the cost out of pocket.
A simple example would be specialized health insurance that only covers the cost of normal delivery of a baby. A man could get this insurance very cheap. A non-pregnant woman could get six month coverage for almost nothing. Someone two months pregnant would probably pay 95% of the cost of the service for the coverage (she might not deliver). Someone eight months pregnant would pay about the actual cost of the service for the insurance. Every one of them would be stupid to buy the insurance. Insurance is for rare events that you are not likely to experience and that you couldn't afford if you were unlucky enough to need it but not have it.
Paying ransom is almost always a bad idea for the community as a whole. The authorities are simply trying to make the company do the right thing instead of the selfish thing. The biggest problem with security is that the incentives are rarely aligned with the responsibilities; this is a classic case of re-aligning those by pushing the societal cost back to the people who are in a position to make the decision.
It is impossible to have both. GPUs are only about 2000 times faster than CPUs at calculating hashes. A reasonable password policy ensures that passwords won't be cracked before users have time to react (usually months or years). Your example would require that a GPU be tens of billions of times faster than a CPU at hashing.
Quit pushing the solutions on the users. You don't need to use longer passwords to make it harder to reverse password hashes, all you need to do is salt the passwords and use iterative hashing (key stretching) to make each guess take longer. In a well designed system, it should take 200 days to brute force passwords for 1000 users, assuming all users had three character lowercase alphabetic passwords. This is base on tuning the number of hash iterations so that a guess takes 1 second to verify.
Taking the information into the article into account, there is a new wrinkle. The application will be using the CPU to compute hashes an attacker might use a GPU based approach. The numbers for the article show the GPU to be about 1500 times as fast as a CPU, getting the horrible passwords from the previous paragraph in about three hours. However, those were absolutely horrible passwords. By tweaking the password policy so that passwords must be five characters long (still no requirement for mixed case or non-alphas), we could still see passwords take 1 second to be verified in the application and the 1/1500th of a second for the GPU based attack would still require 91 days to complete brute forcing the entire database. Of course, nothing will help the users with passwords that are at the top of the dictionary. The best part about iterative hashing is that if we have the same discussion twenty years from now, we simply tweak the number of hash iterations and we get exactly the same results.
Draw out the communications architecture of your system and only allow those communications paths that are necessary. For example, users won't need to send packets to database servers.
Look through the OWASP guidelines, make notes, and do a thorough code review. No matter how secure the systems are, the application must be secure too. There is a lot more knowledge out there on securing OSes and Web Servers, leave that to your hosting company. You need to concentrate on your application.
There is only enough arable land in the world to feed five or six billion people on non-GMO crops. If we get rid of genetically modified crops, who decides who dies? I agree that we need to fix the intellectual property laws that drive Monsanto's worst behaviors, but they are absolutely necessary to the survival of the current generation of humans. Norman Borlaug already proved that billions can be saved and he predicted that we will have to double crop yield again by 2050 to prevent mass starvation.
Does your need to eat "natural veggies" outweigh the needs of others to eat at all?
Except that adding another server to handle more load will cost a couple grand per seat on Windows (Hardware plus licensing) where on an OSS platform you only pay for the hardware.
The retail cost of Windows Server 2008 R2 Web Server Edition is less than $500.00 per server. That will only inflate the cost of a decent server and the labor to set it up by 10 to 20 percent. At the early stages of this project, a few hundred dollars is likely to be a good trade off for not having to learn a new set of development tools and a new language. All non-production licenses are covered in the licensing that comes with Visual Studio.
Of course that's because formation and/or elimination of synapses is the perfect definition of "brain rot", rather than a normal part of maturing, and the ability to pay attention is strongly correlated with being a "perfect cog". If anything, I'd say the opposite is true; easily distracted people should be far more pliable than those who have the ability to focus their attention on something.
It's interesting how many people react emotionally to this article. It looks to me like pretty boring science that may someday help in diagnosing a particular form of ADHD. However, a lot of people seem to want to link the "too much brain" statement to intelligence (the article literally meant grey matter volume in one region of the brain, not intelligence).
The article doesn't say that more intelligent people are more easily distracted. It says that a specific region of the brain has more grey matter in children than in adults. When some adults fail to prune the extra grey matter, they tend be more more easily distracted than those who develop normally.
Slashdot Mirror
Software engineering is fairly similar to structural engineering. Just as an architect does not truly understand how to create an indestructible building without first learning how buildings are destroyed, you can't possibly hope to create a secure software system without understanding how software is broken.
Earthquakes don't adapt their attack strategies as well as hackers. Learning to hack will help you harden against the lamest attacks of five years ago. Every single buffer-overflow can be fixed by simply keeping up on patches. Every SQL Injection vulnerability can be fixed by using a proper database access layer.
I find it much more effective to first apply basic coding standards based on OWASP, then to think of every web page from a request-response perspective instead of from a user perspective. 90% of the stupid security coding I've seen came from somebody who never considered that an attacker doesn't have to be using a standard web browser. Once you get over that hump, there is no value in learning all of the script-kiddie tricks.
I also find that security professionals often lack perspective. I once had a security guy go into great detail showing me how a page was vulnerable to cross-site request forgery and replay attacks. I told him "It's a catalog page, I don't care who reads it. It's URL-parameterized so that my customers can email links to each other. In other words, I'm counting on CSRF for sales.". The funny part is that if I had used URL rewriting instead of a query string parameter, he wouldn't have even known the feature existed.
I am a firm believer that security belongs in the application team. Engaging an outside expert tends to send the message that it's somebody else's responsibility to do security. In reality, security is everyone's problem.
That's easy to game. IT is generally the "say no" department, so if you need to have someone talk you up to the boss, simply turn off the FaceBook filter for someone while you're working on a ticket. Or maybe do shoddy work on the PITA users because their feedback is going to be ignored anyways so you have extra time to bring coffee to one of the more respected users. There are a ton of things you can do to elevate the metric without actually doing better work. On the other side of the coin, being rude is a near guarantee that you will get horrible feedback. I'm not saying it's OK to be rude to people, but I am saying that politeness is over-represented in satisfaction metrics to the point where incompetent but good-natured people will never get poor feedback, even if they never solve a single problem.
So, you do a half-assed job, but remove their firewall restrictions and install a few games while you are at it. Instant satisfaction ratings while simultaneous not getting work done. As soon as a whiff of a mediocre satisfaction report comes in, the hammer comes down and everybody realizes that as long as they keep filling in "excellent" on the surveys, the party can continue.
All help desk metrics are useless. The best guy should be assigned the hardest cases, but that pushes his numbers down. Level three gets all of the impossible cases and is the final word when the answer is "no", so they get lower satisfaction ratings. Cheery chick that closes 20% of her calls, but is very pleasant to listen to and is very nice while transferring 80% of her calls to level two gets stellar ratings. The grumpy guy who has zero social skills, but has memorized every support resolution in the database and gets people off the phone with their problem solved buy saying "moron" and hanging up on them is the biggest productivity booster in the entire company, but he makes people feel bad about themselves, so he gets fired.
I got talked to one time for having a ticket open for two years. The ticket was for a real bug the really did negatively impact the user. However, it was never a high enough impact to get a manager to sign off on the change control to get it implemented. My boss coerced me into closing the ticket with a nebulous resolution because his manager didn't like what it did to the numbers. In summary, the people who review and judge the numbers asked for the numbers to be fudged so that they would be happy with the numbers when they reviewed them.
This is too easy to game. I used to work at a training center where our most important metric was post-class evaluations. One day, some brainiac decided that merit raises would be decided solely on evaluation scores. From that day on, nobody got under 95% on evaluations and the difference between the best and the worst was statistically insignificant. If you want honest metrics, you have to collect them for their own sake and not actually use them. As soon as you tie incentives and punishments to them, the people being measured start spending all of their waking hours figuring out how to artificially inflate them. The only good metric is a metric that you want employees to game, like "Units Produced That Pass QC per Hour".
...".
If you're wondering how we did it, we used to do the following:
1. Force students to hand the evaluation to us after they fill them out. The easiest way to do this was to trade evaluations for certificates. Simply tell them that you have to do it this way because their feedback is important and it's the only way to ensure that everyone turns in an evaluation.
2. Say the following as you pass out evaluations; "Your feedback is very important to us. We don't simply want to know that we aren't doing an excellent job, we need to know how to remedy our shortcomings. So, please, if you give me any score below the highest score, include a detailed comment so I know exactly what I need to improve." 90% of students would give you perfect scores simply because they didn't want to write any comments.
3. Use the specific wording on the evaluation during class. For example, if one of the evaluation ratings is "Used Analogies Effectively", then make sure to lead off any analogy with the phrase "I good analogy for this might be
4. Be a pretty girl and flirt. Seriously, our worst instructor got the highest evaluation scores. However, her scores had a strong positive correlation to the percentage of male students in her classes. I did the math once, the correlation was at least r=0.8. Lucky for her IT training students are predominantly male.
If you are ever in a training class and hear any of these things, give the instructor down the middle scores for being an evaluation-whore.
Yup. However, having just had one of my applications scanned by one of these tools, I can say that if you fail one of these scans, you're app is worse than it says it is. I got a mostly clean bill of health, but the feedback I got was ridiculous. For example, the security department says that all pages of all publicly facing web apps should use SSL. Fine. But, the scan dinged me for caching pages delivery by SSL. So, do I violate the mandate to use SSL on trivial data? Do I violate the common sense approach of adding cache-control directives to static trivial elements like company logos? All the scan did for me is make me spend 4 hours justifying why the scan was worthless.
No, he's saying that it's expensive to say exactly what he wants, and that offsets all of the savings. At the end of the day, it's the thinking that's expensive not the typing. If you move the typing to India, but don't move the thinking, then you've hired a typist instead of a programmer.
Right, because there are no sociopaths working in engineering. No, weapons design themselves. So do fighter jets! Wow, thank you idealistic nerd!.
Yes, one counterexample proves a correlation invalid. Are you a manager, or just a sociopath?
Get over yourself, just because you can't work with people doesn't mean those that do are sociopaths.
It's well documented that people with sociopathic personality traits succeed in management. Also, I don't need to "get over myself", I do work with people. I've been successful in both training and management.
We do make more money than you and don't need to learn new languages and processors and OSes at our own expense every six months.
So, in a thread about engineering education, you bring up learning languages and OSes and paying for your own training. You do know that engineers and programmers are different set of people, right?
Funny thing... 6000 freshmen are admitted to my Alma mater's School of Engineering every year and fewer than 1000 graduate every year. The other 5000 simply can't do the work.
That sounds like a failure to teach.
Some things are unteachable. Some things are so hard to teach that it's easier to simply select students that exhibit the behavior instead of trying to instill the behavior in students that don't exhibit it (especially if the job market only needs as many as, or fewer than, there are natural candidates). Engineering is the second. It's hard to let go of the physical world and replace it with mathematical abstractions. Some people get it and some people don't. Those that don't can compensate for a while by learning how to do every problem form, but they'll eventually get tired and choose to do something else. Those that can do it find engineering fun and rewarding. A good teacher might be able to help a few extra percent "get it", but any more isn't really realistic.
Engineering isn't the only discipline that works this way. There are studies that show that bad programmers can never be turned into good programmers. You can't make someone a great musician through practice alone. Some people will never be good at sports.
Just because somebody plops down $170,000 to go to Cornell and gets accepted doesn't mean that the university must spend as much time with the student as necessary to make them succeed. Good engineering schools don't guarantee that all entering students will come out the other side qualified, they guarantee that all the student that do come out the other side are qualified.
Blaming the teachers for the dropout rate is similar to the "no child left behind" mentality. Asking teachers to spend their time and effort on those with the least chance of success while ignoring those with a greater chance of success will produce a lot of mediocre results. Asking teachers to give everyone the same opportunity to be their best will produce some successes and some failures. The ratio of successes to failures will be primarily determined by the students' potential, not the teachers skill. MIT has a graduation rate over 90% because they only admit the brightest (and most motivated) in the country, not because they have the best faculty.
You seem to have gone to a bad university. I have an engineering bachelors degree and my freshmen classes were full of practical problems, fun labs, and information that was obviously going to be the foundation of everything we were going to learn. Funny thing... 6000 freshmen are admitted to my Alma mater's School of Engineering every year and fewer than 1000 graduate every year. The other 5000 simply can't do the work. It's not a matter of the faculty not teaching them well enough, the students simply decide that engineering is too much work and there are others ways to make a living. I don't blame them, an MBA and a sociopathic attitude will get you a lot more money for a lot less effort than an engineering degree will.
Which is why, if the US is blatently attacked, they will respond with troops and bombs instead of cyber retaliation. That's one of the points of making the Internet a 5th domain. I would envision a typical response to be either cutting off the Internet connections from an attacking country (by physically destroying the cables with air strikes), or pinpointing the location of the attackers and turning them into red mist.
I think it's screwed up that foreign workers have to pay into a retirement system they will never see a nickle from.
Social Security isn't a retirement system. It's a social safety net funded by a specific tax. A quarter of the recipients of Social Security benefits aren't of retirement age, guess where their money comes from? The biggest problem with Social Security is that many people see it as a system that holds on to your money and gives it back to you when you retire. Foreign workers living here benefit from the fact that we don't simply cast out those that cannot support themselves and make them fend for themselves.
120Hz doesn't fix the major problem; expensive glasses. The interleaved method is used to support passive glasses. Alternating between full-resolution right and left eye images will always require active glasses.
It happens enough to require some concrete explanation other than ignorance. There could be a few possible explanations, from the customer service department demanding to know user's passwords in order to help customers more quickly, to someone in IT deciding storing clear-text password will allow a simpler shift from one back-end to another at some time in the future. Since these reduce a small amount of pain on the organization and the loss of passwords brings no pain (except to their customers), the insecure method wins the trade-off.
BTW, I am currently in the middle of a back-end migration where having hashed passwords is causing me some pain. My life would be much easier if these passwords were stored in clear text. I realize that this is simply the cost of reasonable security, but some people might see it differently, especially if they don't value their customers at all.
They wouldn't be too bad. The ability to buy insurance the day before you need it implies that the need can be predicted very accurately. So, if you were due to make a claim tomorrow, your premium would suddenly go up based on your elevated risk level. If you weren't due to make a claim tomorrow, your insurance would still be cheap; possibly nearly free since it the insured event is highly predictable and you aren't due. In the most extreme variation of this theme, insurance would cost about the same as simply paying the cost out of pocket.
A simple example would be specialized health insurance that only covers the cost of normal delivery of a baby. A man could get this insurance very cheap. A non-pregnant woman could get six month coverage for almost nothing. Someone two months pregnant would probably pay 95% of the cost of the service for the coverage (she might not deliver). Someone eight months pregnant would pay about the actual cost of the service for the insurance. Every one of them would be stupid to buy the insurance. Insurance is for rare events that you are not likely to experience and that you couldn't afford if you were unlucky enough to need it but not have it.
Paying ransom is almost always a bad idea for the community as a whole. The authorities are simply trying to make the company do the right thing instead of the selfish thing. The biggest problem with security is that the incentives are rarely aligned with the responsibilities; this is a classic case of re-aligning those by pushing the societal cost back to the people who are in a position to make the decision.
So, when do you forsee GPUs getting to the "tens of billions of times faster" that I mentioned above and is necessary for your comparison to be valid?
It is impossible to have both. GPUs are only about 2000 times faster than CPUs at calculating hashes. A reasonable password policy ensures that passwords won't be cracked before users have time to react (usually months or years). Your example would require that a GPU be tens of billions of times faster than a CPU at hashing.
Quit pushing the solutions on the users. You don't need to use longer passwords to make it harder to reverse password hashes, all you need to do is salt the passwords and use iterative hashing (key stretching) to make each guess take longer. In a well designed system, it should take 200 days to brute force passwords for 1000 users, assuming all users had three character lowercase alphabetic passwords. This is base on tuning the number of hash iterations so that a guess takes 1 second to verify.
Taking the information into the article into account, there is a new wrinkle. The application will be using the CPU to compute hashes an attacker might use a GPU based approach. The numbers for the article show the GPU to be about 1500 times as fast as a CPU, getting the horrible passwords from the previous paragraph in about three hours. However, those were absolutely horrible passwords. By tweaking the password policy so that passwords must be five characters long (still no requirement for mixed case or non-alphas), we could still see passwords take 1 second to be verified in the application and the 1/1500th of a second for the GPU based attack would still require 91 days to complete brute forcing the entire database. Of course, nothing will help the users with passwords that are at the top of the dictionary. The best part about iterative hashing is that if we have the same discussion twenty years from now, we simply tweak the number of hash iterations and we get exactly the same results.
This problem is trivial to defend against. Simply employ key stretching. You can make it take as long as you want.
Draw out the communications architecture of your system and only allow those communications paths that are necessary. For example, users won't need to send packets to database servers.
Look through the OWASP guidelines, make notes, and do a thorough code review. No matter how secure the systems are, the application must be secure too. There is a lot more knowledge out there on securing OSes and Web Servers, leave that to your hosting company. You need to concentrate on your application.
There is only enough arable land in the world to feed five or six billion people on non-GMO crops. If we get rid of genetically modified crops, who decides who dies? I agree that we need to fix the intellectual property laws that drive Monsanto's worst behaviors, but they are absolutely necessary to the survival of the current generation of humans. Norman Borlaug already proved that billions can be saved and he predicted that we will have to double crop yield again by 2050 to prevent mass starvation.
Does your need to eat "natural veggies" outweigh the needs of others to eat at all?
The time to ask for equity instead of pay was back when there was risk.
Except that adding another server to handle more load will cost a couple grand per seat on Windows (Hardware plus licensing) where on an OSS platform you only pay for the hardware.
The retail cost of Windows Server 2008 R2 Web Server Edition is less than $500.00 per server. That will only inflate the cost of a decent server and the labor to set it up by 10 to 20 percent. At the early stages of this project, a few hundred dollars is likely to be a good trade off for not having to learn a new set of development tools and a new language. All non-production licenses are covered in the licensing that comes with Visual Studio.
Of course that's because formation and/or elimination of synapses is the perfect definition of "brain rot", rather than a normal part of maturing, and the ability to pay attention is strongly correlated with being a "perfect cog". If anything, I'd say the opposite is true; easily distracted people should be far more pliable than those who have the ability to focus their attention on something.
It's interesting how many people react emotionally to this article. It looks to me like pretty boring science that may someday help in diagnosing a particular form of ADHD. However, a lot of people seem to want to link the "too much brain" statement to intelligence (the article literally meant grey matter volume in one region of the brain, not intelligence).
The article doesn't say that more intelligent people are more easily distracted. It says that a specific region of the brain has more grey matter in children than in adults. When some adults fail to prune the extra grey matter, they tend be more more easily distracted than those who develop normally.