Were any of the patches linked above installed by someone's grandmother?
The problem with your "properly written" qualifier is that it presents an inherently problematic challenge. LastPass says that it operates the correct way, but how can I verify that? Because their website says so? I have no meaningful way to acquire proof that it does what it's supposed to do. Additionally, if I do may unique, gibberish-string passwords, I officially become dependent on LastPass; that dependency has its own points of concern. It may not convenient to have passwords written in a book that's left at home, but its tradeoff between "not being available in a grocery store" and "not being susceptible to LastPass hacking / ending service / software vulnerabilities / NSL" has definite advantages on both sides.
First of all, while the physical book of unique passwords for every site is the best solution as far as security goes, the average user isn't going to be able to deal with not having access to xyz.com in the grocery store. It's much easier to be lazy and use the same password everywhere and store that in the browser's crappy, unencrypted password manager so they don't even have to put in the effort to remember it.
You are right in that Lastpass does provide an auditing challenge. As you noted earlier, even if it was 100% FOSS, (I would love it if it was) I, and most other people, do not have the skills to correctly audit it anyway. There are other open-source alternatives out there that can be audited but they usually require bringing your own "cloud" and thus are more difficult for novice users to use. Luckily, if you are really concerned about LastPass, you can do a packet capture to verify it is only storing properly encrypted data.
If LastPass really does what they claim, hacking/NSA isn't an issue (because you already verified via a packet capture that your data is only uploaded to them in an encrypted form, right?) If your master password gets brute-forced it's your own fault. Ending service isn't an issue because there's nothing stopping you from clicking on "Tools -> Advanced Tools -> Export To -> CSV File."
I'm not saying LastPass, KeyPass, etc... are perfect but they are 1000x better than using Kitten1 as a password everywhere like the average person does. I suspect Joe Schmoe's blog where Mr. Average commented once is easier to hack than LastPass and a hack there will likely give the attacker access to Average User's inbox just like a worst-case LastPass compromise. Not using a password manager is the equivalent to giving every site you have an account on the same level of trust you would have to give LastPass or your storage provider where your KeePass file is located. At least with a password manager, you only have to place your trust in one--hopefully security-focused--provider whose primary business model is keeping your data secure.
I don't dispute that. The point I was making was that updates are not universally better than their predecessors. Yes, I rolled that firmware back, but the fact that I needed to do so was more where my objection was focused.
It is fair to say that security updates are better than their predecessors which is what I'm pretty sure the experts were talking about when they talk about patching. Feature updates are kind of out of the scope of the article (although some vendors don't make much of a distinction which makes it hard for novice users to determine whether an update should be installed or not, but this is 100% the fault of shitty vendors.)
Sounds like the people testing software in your company suck at your job. It also sounds like the people writing that particular software suck at their jobs too if it happens monthly. I realize you can't test for every use case but testing 90% of what a user is going to do should limit support calls quite a bit and will be less of a financial risk overall than being exploited by whatever zero day the security update is patching.
"Experts" are much better equipped to work around an update that makes a mess, and "Experts" are better able to pick up UI changes than "Non-Experts". Security is a good reason to update/upgrade, but every non-expert I know whose phone got the Lollipop update described it with obscenities, and would have been perfectly fine with a 'security patch only' update. The problem is that there's no consistent way for non-experts to know whether this will be a "transparent security fix" kind of update, or a "this will f'k up my s't and rearrange everything for no good reason" update. Even updates that don't make a mess of the UI cause other problems. Windows XP, circa 2001, needed 256MB of RAM to run acceptably. by the end of its run, the UI hadn't changed, but somehow, it required at least 1GB of RAM when it was (supposedly) the same OS. Admittedly an obscure example (but the only one I can think of at the moment), an Intel wireless NIC driver update I did once removed the ability to specify my own MAC address. A router firmware update I did once notably decreased the throughput of the network traffic it was processing. We all remember the Slashdot outcry when Sony removed OtherOS from the PS3. "Update" has a long history of having mixed impact on end users, so any "Expert" who both unilaterally applies updates and doesn't understand why "Non-Experts" don't share this practice may well have a thorough understanding of computers, but a piss poor understanding of humans.
I didn't see any experts in the article suggesting blindly installing updates without testing (if possible, like in a corporate environment for instance) or reading the release notes. Anyone with the technical skill to be upgrading a NIC driver or a router firmware should also have the technical skill to A) Test the update, B) Read and understand the release notes, and C) roll back the update if it has unintended side affects
Many password managers use Teh Cloud (tm). There's a damn good reason to be reluctant to store all of your passwords on somebody else's hard disk. Local password managers solve that problem, and now we're back to the classical problem of 'backing data up' and 'single point of failure'. Even at that, who do you trust? Heartbleed was a particular mess from a PR perspective because Open Source ("More secure than Microsoft!!11") had a spectacular failure that was used by "Experts" - people who were supposed to be putting security at the forefront. If such a widely circulated OSS project could have such a problematic bug, what possible hope does a regular user have with respect to betting on the right horse? Even if they do, there's nothing that they can do for the far end doing stupid things - all the password managers in the world won't change a blessed thing if the password was for Sony or Ashley Madison. It's all risky at some level, and ultimately, password managers overcome a shortcoming of computers themselves. Non-Experts have things to do. Writing passwords down in a nondescript password book, kept in a room separate from the computer itself, with each of the passwords changed annually, is probably the simplest and cheapest way a non-expert can put themselves comfortably in the third standard deviation.
All software has bugs. Security is always a trade-off between convenience and usability. A properly written "Cloud" password manager *CAN* do both by only storing the encrypted information in the cloud. It also encourages (and can generate) unique and random passwords for each site. That way when Sony or Ashley Madison get hacked, the perpetrator gets a unique random password that won't give them access to anything else. A properly-written cloud based (all encryption is handled locally, plaintext is *NEVER* in the "Cloud") password manager has the added benefit of working on mobile platforms where the physical book in the other room can't help you if you are on your laptop in the coffee shop or on your phone waiting in line at the grocery store.
Funny how you mention the attention Heartbleed got but you fail to mention Microsoft's way worse SSL/TLS screwup last year which didn't get a fancy name or any media attention. Like I said, all software has bugs.
I didn't see anywhere in the article that the security experts suggested blindly installing updates without testing them first.
I suspect the "Password Managers" referred to in the article are third-party utilities like KeePass or LastPass and not the insecure-by-default and feature-lacking password managers provided by the browser.
[quote]The downloading of these invisible ads can slow down users' phones and consume up to 2GB of bandwidth per day.[/quote]
While this is an interesting revelation, I'm not really sure what the fear-mongering is all about. What is Forensiq trying to sell here?
For what it's worth, the local school district in my area rolled out arm-based samsung chromebooks to all students 7th grade and above 2 years ago. All of them that I have seen are a little scuffed up but still intact over that amount of time. Given the price point is much cheaper than an ipad and it can be used for useful things like word processing, etc... I would say this is a much better deal for the school.
Honestly, what is the educational value in an iPad really to middle and high school students? The school is still using textbooks so it's not that...
I can't think of a name that would poke any harder at Apple.
The T-Bird's ignition is timed a solid-state electronic ignition control module that reads the timing from a sensor and grounds the coil causing the high-voltage burst of electricity that fires the spark plug. The role of the distributor is to select which spark plug should spark. Prior to the invention of electronic ignition, gasoline engines used a set of mechanical points that rode on a cam lobe under the distributor. When it came time to fire a spark plug, the points would come in to contact with each other and cause the coil to ground. This is the system used by the '68 Plymouth.
All fuel injectors for gasoline-powered road cars (mechanical injectors were used in racing for a while and were used for many years in diesel engines) are controlled by an ECU. Early Bosch fuel injection units used in 1960s VWs used an ECU the size of a small suitcase. When EFI became more mainstream in the mid '80s the ECU was significantly smaller. They weren't nearly as complicated as modern ECUs--they just ran a loop reading a few sensors and adjusting fuel injector speed and duration.
Starting the engine has been pretty much the same since electric start came out in the early 1920s if not earlier. A big relay (or in really old stuff a big switch) sends lots of amps to a powerful electric motor that turns the engine over. Even if the motor did get fried by an EMP, the '68 plymouth likely has a manual transmission and could be roll started.
For the record, your '84 T-Bird was a piece of shit. So was my '84 Mercury Cougar
Your '84 T-bird was fuel-injected and had electronic ignition. It was in no way EMP-proof.
Here's a solution I figure just about every "privacy troll" can probably agree with:
The NSA needs to stop collecting data on US citizens. If a US citizen needs to be investigated, it's the FBI's job to do that investigation.
If the FBI wants to collect data on a US citizen, they should get a warrant the normal way. None of this secret court nonsense.
1) Remove keyboard/mouse
2) slide monitor down, almost facing up (as you currently do with your smartphone.
3. Enjoy a sore neck from looking down, slow input, and fingerprints all over your screen.
Sure you could cobble together a bit of this and a bit of that that sort does something similar, but it takes 10x as much effort, only has 1/2 as many features, and is a nightmare to support or troubleshoot when it breaks (or a new guy comes onboard and has to figure out your homebrew mess you created.
It's not cobbling stuff together, it's a different thought process for tackling a problem. Rather than having one big mess provided by Microsoft, you have lots of individual parts that do one thing well and are configured to work together--see the LAMP stack for an excellent example.
A new employee doesn't have to figure out the "homebrew" mess, they just have to know how to manage the application(s) they are responsible for--A skill that is vastly lacking with most Windows Server admins I have met--no, rebooting a server does not "fix" the fact that every 5 days the server is at 5% load with 95% memory utilization.
Most of Microsoft's problems in the server space is that the products ship with 10x more "features" enabled than are actually needed. This makes for loads of time disabling things or having vulnerable servers. A properly managed unix-based solution usually has 100% of the needed requirement--no more, no less. This limits exposure to security issues and limits the effects of bugs or bad code on the overall health of the system.
[quote]dd if=/dev/random of=/dev/sda[/quote]
I would suggest using