Microsoft introduced HTTP.SYS in Server 2003 to improve IIS 6.0 performance. They really wanted to beat Apache.
Each application pool has a dedicated request queue in HTTP.SYS, which provides very fast and low-latency network performance. This advantage may have been more significant on the slower machines of the time than it is today.
I am not a web developer or web admin, so I don't know how important the performance is---but I doubt it outweighs the security shortcomings.
As other OS functions (such as Windows Update) use the functionality provided by HTTP.SYS, this insecure design is difficult to fix.
Everyone sounds revolutionary in whitepapers when they're looking for money. See if that revolutionary talk sticks around after they mass-produce their new hardware and have to support it. That's always when the magic disappears.
Transmeta couldn't build anything that competed with Intel's offerings. The power consumption was lower, but the performance sucked. They were about a generation ahead on power consumption but about 2-3 generations behind on performance.
Code morphing has an inherent penalty---negligible for some instructions, severe for others. Same for emulation. Now that Intel is focusing on performance per watt, these "efficient" architectures are going to get buried by a truly efficient native x86 implementation.
Transmeta existed in an environment where Intel was focused on improving performance almost exclusively. They had a little niche of the market all to themselves, and they couldn't even survive then. Now that Intel cares about power consumption, I wouldn't bet on anyone else gaining a foothold.
You might think something like that unless you actually read the article.
From the description and the diagram, it appears rather clear that they are acting as a local seed for clients on their network.
This is an obvious win-win. It reduces their transit to other networks and keeps BT traffic off their backbone routers (provided the "local peer servers" are distributed regionally). Users get higher speeds from a virtually dedicated seed connection.
The obvious downside is that the ISP knows which torrents are being downloaded by which users, so there are potential privacy or legal issues. From a technical standpoint, however, both the ISP and the users would see an improvement.
This is actual innovation from an American ISP. I'm shocked that it happened, and even more shocked that people are upset about it.
That does not work since he is accessing Amazon, Netflix, and whatever CDNs are caching his shows.
With the growth of online video and IoT devices---and their resulting need for CDNs, redundancy, and resilience vs load/DDoS---simple IP filtering is becoming increasingly difficult for even a modestly connected household. And the difficulty is only going to increase over time.
I'm at the point where I'm about to give up on manual filtering entirely, and I don't have a lot of the shiny new networked devices. In the past, "dumber" devices have ended up being relegated to the cheapest bargain-basement hardware on the market. There are very few premium "dumb" devices anywhere.
I want privacy and security, and I want those things without being forced to buy the bottom-of-the-line crap. If they don't stop making invasive, insecure "smart" devices, I see bigger problems looming.
Corporations have an obligation to follow the laws and make a profit.
And if we notice any behaviors harming our overall social environment while simultaneously enriching businesses, we can pass laws to prohibit those behaviors.
It's certainly feasible to prohibit known-bad behaviors preemptively rather than waiting for the market to discover and react to individual acts of malfeasance or breaches of trust.
In addition, a violation of established regulations or commerce law generally provides firm legal footing for a civil suit against the violators. These cases tend to be litigated much more quickly and successfully. Or settled without taking the matter to court at all, which is really ideal.
1. They probably derive from value from the vendor lock-in than they expect from sharing. The rival OSes can already join an Active Directory domain (some require third-party tools, some don't). Right now, if you want to manage a fleet of Windows desktops you need a few Windows Server licenses for your domain controllers---and the requisite CALs. There are already open source AD clones anyway, which is probably why 2008, 2008 R2, and 2012 functional levels have such nice new features. They want to maximize the number of Microsoft products you're using.
2. Until Microsoft storage demonstrates the reliability of EMC or Compellent, no one is going to care. Linux and Windows can both work as an iSCSI target, and that's good enough for people who want cheap, accessible storage. Customers who already demand reliability and performance are paying for it because they need it. Maybe there is a bigger market for people who could benefit from some middle tier of storage, but there are plenty of vendors in that range too. So, the question still boils down to "Why put that storage in a server and trust Microsoft to present it?"
3. At the enterprise level, if you're relying on AV detection to find malware, you're already behind the curve. Most of the new security features are targeted at the network-connected enterprise machines, with some trickle-down benefits for consumers. The VM/hypervisor idea will wreak havoc on the two performance areas that matter for Windows desktops---CAD and gaming. While I agree with the principle, it's not happening. Microsoft started research on Singularity almost 10 years ago, and little of that work has shown up in Windows.
Modern versions of Windows (Vista and newer) will find your license server automatically, unless you configure either your OS image or your license server to do otherwise.
It's a simple matter of having the right SRV record in DNS, and the license server will add it automatically if it's setup by a user with the necessary privileges.
The current license server supports all modern Windows versions. I wonder if that will change once Vista leaves its extended support phase. I expect it will take minimal effort to maintain activation support for an older OS, so I doubt they will simply drop it and risk irritating their enterprise customers. At this point, they're the only ones willing to pay a substantial amount of money for an operating system license.
If the company had a history of never patching vulnerabilities or even being spotty and refusing to support new products, then it makes sense to out them immediately.
But Microsoft has been issuing monthly patches for supported versions of Windows for years.
Yes, they'll delay or rescind a patch once in a while when it breaks things. Any company can be in that position though, and that's OK too provided they reissue a good patch when it's ready.
Instead of publishing exploit details and POC code automatically after 90 days, they should publish mitigation measures immediately (to actually help admins secure their assets) and sit on the more technical details for longer than 90 days if they reasonably expect the vendor to issue a patch. Maybe set a hard cap of 180 days to avoid being strung along indefinitely. While 90 days is a good starting point, no two bugs are the same.
An automatic one-size-fits-all approach is draconian and stupid. Some bugs require multiple rounds of testing because things get broken unexpectedly by the first "fix". Large software projects often end up with hidden dependencies that complicate bugfixing; it's a fact of life, and ignoring reality in favor of ideologically-driven rules usually ends poorly.
The fact what they think went wrong was insufficient hydraulic fluid, and not their engineering process that allowed a major mistake to make it into the design and not be detected during testing, is the *real* problem.
It was detected during testing. Their entire retrievable/reusable concept is being developed and tested right now. Their contractual requirement is to put payload into orbit. The landing mechanism is merely an economic advantage for the company that will keep their costs lower; their contracts certainly don't specify it as a requirement.
Some shops use an iterative design process. It usually comes with being new to the market (and thus lacking the funds for extended pre-operative testing).
Some shops even do iterative design as standard practice when they are well-funded.
They were only required to launch supplies to the ISS. The ability to test and refine their landing mechanism is a bonus for the company. Hell, NASA's other contractor doesn't even have a reusable vehicle.
In conclusion: Do you know what we call a service that fulfills its contractual requirements? A success.
The Windows Store has more granular permissions, restricted UI modes, and reduced legacy API support. These things will lead to apps using modern security and UI conventions, which is mostly a good thing.
A curated app store is probably good for normal users. As long as sideloading apps is always supported, this should make some headway on taming the burden of legacy software.
I expect to see an unending avalanche of shitty Win32 apps for the rest of my life, but the Windows Store at least offers some vague hope that it will diminish over time.
Applications and config/data files that need to be available for multiple users can be installed to C:\Users\Public by default without admin privileges. This location is available in an environment variable in case the admin has changed it (can't remember the variable name off the top of my head).
Applications with per-user installation or config files can use the %USERPROFILE% environment variable to find a safe place to store their data (defaults to C:\Users\username). Creating your own directory there is probably a good idea and is permitted by default.
There are guidelines for using the pre-established directories for Desktop, Documents, Downloads, Music, Pictures, and Videos though, since they are shared with the OS and other applications.
Chrome has a Windows installer that does not require elevation. The single-user installer unpacks to a directory in the user's personal profile and runs from there.
Since it cannot install the updater service without admin privileges, Chrome cannot upgrade seamlessly---the browser must be running to detect the update, so it must be restarted afterward. I suspect this is why the standalone installer is not the default option and not widely advertised.
It's clear you don't know where to begin criticizing it. DVDs do it (very poorly) and Blu-Ray do it (less poorly).
You identify two systems as examples of your new "security" feature, but both of them have been laughably compromised. Neither scheme lasted more than a year in the wild, and with a PC security standard you'd need to manage a bit more than that.
A similar system would be trivial. As would be putting the PRIVATE KEYS on the mass produced hardware (encrypted and signed, of course). You do know how PKI works, don't you? You don't send someone your private key for them to authenticate you. You encrypt their public key with your private key and send that encrypted PRIVATE KEY derivative. So, burn that encrypted key into the USB device as part of the driver.
I bolded the part that is problematic. How does one burn a key into the device as part of a driver, exactly? With security, the devil is in the details, and your proposed system sounds no better than similar systems which have failed in the past.
That you are too dumb to understand an idea doesn't mean the idea is dumb.
Nice ad hominem, but maybe you should have provided a substantive argument instead.
I believe your explanation rather than my intelligence is at fault here. You identify two systems as functional examples of your new "security" feature---neither of which is effective in practice. AACS has been compromised repeatedly, which shows that simply revoking the exposed keys and hoping new equipment fares better is not an effective strategy.
Can you explain, clearly, how your system differs in such a way as to render it immune to similar attacks? If not, then there is absolutely no reason to take your proposal seriously.
If you don't see a problem with PRIVATE KEYS being distributed inside mass-produced hardware, I do not even know where to begin criticizing your position.
Every piece of equipment would need significant anti-tampering measures because as soon as the keys are retrieved from one device, it is game over.
This is why DRM software keeps getting cracked over and over in spite of the billions of dollars being spent on developing it. If your scheme requires a secret that the user needs to operate the device, it will be compromised.
People crack stuff like this for fun. We've seen it happen year after year. Do you think there will be more or less cracking attempts when there are serious espionage or financial incentives?
To be an HID, it must announce itself as one (called "driver" even when it just announces itself and requests the default OS driver). To do so, it must authenticate with the host OS. If not, the HID functionality will be disabled.
What? USB devices in general, and HIDs in particular, do not authenticate with the OS when plugged in.
You plug it in, and it negotiates with the host controller automatically. The host controller notifies the OS that the device is there, and then the OS queries the device for its properties. The device is perfectly capable of lying about what it is and what it does.
If the device identifies as a keyboard, mouse, Smart Card reader, or removable storage, by default the OS will load its native drivers and handle the device seamlessly. The device could have nefarious functionality, but the OS has no way of knowing about that.
Various OS security tools and third-party utilities can attempt to restrict the use of USB devices. None of them are pleasant to use---from the standpoint of either the administrator or the end user.
I've been told the problem is when the USB drive is actually a storage device, but leaches power (but no connectivity to the host computer) to broadcast the contents of the device on WiFi to a listening attack machine outside (but in WiFi range).
Not terribly practical or interesting. This idea probably came from someone who watches too many "hacker" movies. Anyone who is concerned about restricting USB devices probably already has a solution for detecting rogue Wifi clients and APs. If not, they can buy one off the shelf. This is something I would expect to see in a Hollywood movie.
Rogue USB devices are not something a hacker is going to use against some random citizen in hopes of scoring access to their checking account. This is something enterprises and governments are going to be worried about, and they have options for mitigating the threat.
Storing authentication credentials in a retrievable form anywhere is stupid, even in memory. Kerberos has been around for decades, and it eliminates the need for a password to exist in memory as soon as it is hashed.
If Kerberos is not practical for a particular application, the same principles can be used in proprietary authentication mechanisms.
A plaintext password should never persist. Period. It is the result of a stupid decision somewhere, and we have known better for a long, long time.
Your theoretically sound system is not practical to implement. Plus, we already have a better solution.
The only problem you've clearly identified with the CA system is already addressed by certificate pinning. Your solution offers nothing of value beyond what I can accomplish with pinning---and your idea brings a whole lot of administrative overhead.
While certificate pinning does require local administration, it is significantly less burdensome than your approach. Even Microsoft supports it now, so it is not some niche security option anymore.
Certificate pinning takes ultimate trust back from the CAs yet works easily with the existing infrastructure for applications that you don't need to control as tightly. I have no idea why you are promoting a system that is more complicated and less compatible with no concrete advantages.
Yes, the lack of a theoretically sound system is a problem. Your "solution" was to disband the existing system without any sort of meaningful replacement.
We can always use PGP/PKI internally and with close associates. But we need some form of identity verification for everyone else in the world too.
The CA system is flawed---but better than nothing at all. Your "solution" returns us to having nothing for the rest of the world. I.e., it is not a solution or an improvement in any meaningful way to what we already have.
So your suggestion is, let's keep all of our super important stuff on a front-end facing system in the first place.
I never said that, but thanks for throwing an asinine straw man up there.
They can probably lock things down better than they did, but I don't work at Sony and I haven't seen their network diagrams so I can't really say. But the idea of air-gapping financial systems for a company of Sony's size is mind-boggling stupid.
Even something as simple as warranty work breaks down without automation. Every authorized repair depot needs some way to order parts, submit claims, and receive payment at an absolute minimum. If you air-gap the systems for that, guess what happens to time and cost of warranty repairs? And this is just one facet of the business.
So right there, you have network-accessible procurement, payment, and personally-identifiable information (customer name/address and product serial number are typically included in warranty documentation). Waving the magical air-gap wand as a security fix means nothing if it fundamentally breaks the way the business operates.
So yes, Sony probably fucked up somewhere. If they're like most businesses, there are probably multiple problems with their infrastructure. But pretending there's a simple answer is just ignorant and does absolutely nothing to advance the discussion or solve any real-world problems.
If you air gap email and financial systems, you're stepping right back into the mid-1900s. Back when it took an entire office of secretaries to process correspondence, and another office full of accountants to handle billing and ledgers. Because if those systems are disconnected, someone will have to transfer reams of data in and out of them. That is no longer feasible.
Your suggestion is so completely impractical, I wonder why you joined slashdog in the first place. You clearly have no understanding of modern IT.
And your solution only works for entities with which you have a pre-established relationship and a shared secret (in this case, your personal information).
This does not solve the general problem of identifying an entity on the internet with whom you have no shared secrets.
This suggestion is nowhere near being a replacement for existing CAs as they are currently used.
If you actually read the article, you would see that they had administrative access to the zone files. Which means they could have changed whatever they wanted. They also had access to usernames and passwords, so hopefully no one used the same credentials elsewhere.
Since non-disparagement clauses are almost exclusively used in severance agreements, there is a disparity in power that makes them practically coercive. I have no problem condemning them in that context.
You seem to be confusing a few things here, though. True statements can be disparaging in nature. Google it if you're inclined to argue because it's rather cut-and-dried---and not worth arguing over.
And no, they do not have to specify what you cannot speak about. If the severance agreement prohibits disparaging statements, it's pretty much carte blanche for legal action if you say anything bad about them. They may not choose to file suit for something as simple as saying, "XYZ Company sucks!"---but they could. You're free to walk away without a severance package if you don't like their terms. Most companies are not willing to negotiate the matter with someone they are in the process of terminating.
Should you happen to disparage the company after signing a typical severance agreement, they can sue for the severance pay and possibly even the cost of benefits during the severance period (if they continued your benefits, of course). They may also be able to recoup their legal fees.
I have seen a lot of people in that situation, and a cavalier attitude never ended well. Unless the employer actually breaks a law, the asymmetry of power is simply too great.
Slashdot Mirror
Microsoft introduced HTTP.SYS in Server 2003 to improve IIS 6.0 performance. They really wanted to beat Apache.
Each application pool has a dedicated request queue in HTTP.SYS, which provides very fast and low-latency network performance. This advantage may have been more significant on the slower machines of the time than it is today.
I am not a web developer or web admin, so I don't know how important the performance is---but I doubt it outweighs the security shortcomings.
As other OS functions (such as Windows Update) use the functionality provided by HTTP.SYS, this insecure design is difficult to fix.
Everyone sounds revolutionary in whitepapers when they're looking for money. See if that revolutionary talk sticks around after they mass-produce their new hardware and have to support it. That's always when the magic disappears.
Transmeta couldn't build anything that competed with Intel's offerings. The power consumption was lower, but the performance sucked. They were about a generation ahead on power consumption but about 2-3 generations behind on performance.
Code morphing has an inherent penalty---negligible for some instructions, severe for others. Same for emulation. Now that Intel is focusing on performance per watt, these "efficient" architectures are going to get buried by a truly efficient native x86 implementation.
Transmeta existed in an environment where Intel was focused on improving performance almost exclusively. They had a little niche of the market all to themselves, and they couldn't even survive then. Now that Intel cares about power consumption, I wouldn't bet on anyone else gaining a foothold.
You might think something like that unless you actually read the article.
From the description and the diagram, it appears rather clear that they are acting as a local seed for clients on their network.
This is an obvious win-win. It reduces their transit to other networks and keeps BT traffic off their backbone routers (provided the "local peer servers" are distributed regionally). Users get higher speeds from a virtually dedicated seed connection.
The obvious downside is that the ISP knows which torrents are being downloaded by which users, so there are potential privacy or legal issues. From a technical standpoint, however, both the ISP and the users would see an improvement.
This is actual innovation from an American ISP. I'm shocked that it happened, and even more shocked that people are upset about it.
That does not work since he is accessing Amazon, Netflix, and whatever CDNs are caching his shows.
With the growth of online video and IoT devices---and their resulting need for CDNs, redundancy, and resilience vs load/DDoS---simple IP filtering is becoming increasingly difficult for even a modestly connected household. And the difficulty is only going to increase over time.
I'm at the point where I'm about to give up on manual filtering entirely, and I don't have a lot of the shiny new networked devices. In the past, "dumber" devices have ended up being relegated to the cheapest bargain-basement hardware on the market. There are very few premium "dumb" devices anywhere.
I want privacy and security, and I want those things without being forced to buy the bottom-of-the-line crap. If they don't stop making invasive, insecure "smart" devices, I see bigger problems looming.
Corporations have an obligation to follow the laws and make a profit.
And if we notice any behaviors harming our overall social environment while simultaneously enriching businesses, we can pass laws to prohibit those behaviors.
It's certainly feasible to prohibit known-bad behaviors preemptively rather than waiting for the market to discover and react to individual acts of malfeasance or breaches of trust.
In addition, a violation of established regulations or commerce law generally provides firm legal footing for a civil suit against the violators. These cases tend to be litigated much more quickly and successfully. Or settled without taking the matter to court at all, which is really ideal.
1. They probably derive from value from the vendor lock-in than they expect from sharing. The rival OSes can already join an Active Directory domain (some require third-party tools, some don't). Right now, if you want to manage a fleet of Windows desktops you need a few Windows Server licenses for your domain controllers---and the requisite CALs. There are already open source AD clones anyway, which is probably why 2008, 2008 R2, and 2012 functional levels have such nice new features. They want to maximize the number of Microsoft products you're using.
2. Until Microsoft storage demonstrates the reliability of EMC or Compellent, no one is going to care. Linux and Windows can both work as an iSCSI target, and that's good enough for people who want cheap, accessible storage. Customers who already demand reliability and performance are paying for it because they need it. Maybe there is a bigger market for people who could benefit from some middle tier of storage, but there are plenty of vendors in that range too. So, the question still boils down to "Why put that storage in a server and trust Microsoft to present it?"
3. At the enterprise level, if you're relying on AV detection to find malware, you're already behind the curve. Most of the new security features are targeted at the network-connected enterprise machines, with some trickle-down benefits for consumers. The VM/hypervisor idea will wreak havoc on the two performance areas that matter for Windows desktops---CAD and gaming. While I agree with the principle, it's not happening. Microsoft started research on Singularity almost 10 years ago, and little of that work has shown up in Windows.
Modern versions of Windows (Vista and newer) will find your license server automatically, unless you configure either your OS image or your license server to do otherwise.
It's a simple matter of having the right SRV record in DNS, and the license server will add it automatically if it's setup by a user with the necessary privileges.
The current license server supports all modern Windows versions. I wonder if that will change once Vista leaves its extended support phase. I expect it will take minimal effort to maintain activation support for an older OS, so I doubt they will simply drop it and risk irritating their enterprise customers. At this point, they're the only ones willing to pay a substantial amount of money for an operating system license.
Takeoff is the absolute worst time for an engine failure.
They still made it from LAX to Manchester with a failed engine. That's pretty impressive.
A dual-engine aircraft would not have fared nearly as well. The best expected outcome would be an emergency landing at the nearest airport.
If the company had a history of never patching vulnerabilities or even being spotty and refusing to support new products, then it makes sense to out them immediately.
But Microsoft has been issuing monthly patches for supported versions of Windows for years.
Yes, they'll delay or rescind a patch once in a while when it breaks things. Any company can be in that position though, and that's OK too provided they reissue a good patch when it's ready.
Instead of publishing exploit details and POC code automatically after 90 days, they should publish mitigation measures immediately (to actually help admins secure their assets) and sit on the more technical details for longer than 90 days if they reasonably expect the vendor to issue a patch. Maybe set a hard cap of 180 days to avoid being strung along indefinitely. While 90 days is a good starting point, no two bugs are the same.
An automatic one-size-fits-all approach is draconian and stupid. Some bugs require multiple rounds of testing because things get broken unexpectedly by the first "fix". Large software projects often end up with hidden dependencies that complicate bugfixing; it's a fact of life, and ignoring reality in favor of ideologically-driven rules usually ends poorly.
The fact what they think went wrong was insufficient hydraulic fluid, and not their engineering process that allowed a major mistake to make it into the design and not be detected during testing, is the *real* problem.
It was detected during testing. Their entire retrievable/reusable concept is being developed and tested right now. Their contractual requirement is to put payload into orbit. The landing mechanism is merely an economic advantage for the company that will keep their costs lower; their contracts certainly don't specify it as a requirement.
Some shops use an iterative design process. It usually comes with being new to the market (and thus lacking the funds for extended pre-operative testing).
Some shops even do iterative design as standard practice when they are well-funded.
They were only required to launch supplies to the ISS. The ability to test and refine their landing mechanism is a bonus for the company. Hell, NASA's other contractor doesn't even have a reusable vehicle.
In conclusion: Do you know what we call a service that fulfills its contractual requirements? A success.
Pretty much.
The Windows Store has more granular permissions, restricted UI modes, and reduced legacy API support. These things will lead to apps using modern security and UI conventions, which is mostly a good thing.
A curated app store is probably good for normal users. As long as sideloading apps is always supported, this should make some headway on taming the burden of legacy software.
I expect to see an unending avalanche of shitty Win32 apps for the rest of my life, but the Windows Store at least offers some vague hope that it will diminish over time.
Applications and config/data files that need to be available for multiple users can be installed to C:\Users\Public by default without admin privileges. This location is available in an environment variable in case the admin has changed it (can't remember the variable name off the top of my head).
Applications with per-user installation or config files can use the %USERPROFILE% environment variable to find a safe place to store their data (defaults to C:\Users\username). Creating your own directory there is probably a good idea and is permitted by default.
There are guidelines for using the pre-established directories for Desktop, Documents, Downloads, Music, Pictures, and Videos though, since they are shared with the OS and other applications.
Chrome has a Windows installer that does not require elevation. The single-user installer unpacks to a directory in the user's personal profile and runs from there.
Since it cannot install the updater service without admin privileges, Chrome cannot upgrade seamlessly---the browser must be running to detect the update, so it must be restarted afterward. I suspect this is why the standalone installer is not the default option and not widely advertised.
The latest version is always linked at https://support.google.com/ins... if you need to grab a copy.
It's clear you don't know where to begin criticizing it. DVDs do it (very poorly) and Blu-Ray do it (less poorly).
You identify two systems as examples of your new "security" feature, but both of them have been laughably compromised. Neither scheme lasted more than a year in the wild, and with a PC security standard you'd need to manage a bit more than that.
A similar system would be trivial. As would be putting the PRIVATE KEYS on the mass produced hardware (encrypted and signed, of course). You do know how PKI works, don't you? You don't send someone your private key for them to authenticate you. You encrypt their public key with your private key and send that encrypted PRIVATE KEY derivative. So, burn that encrypted key into the USB device as part of the driver.
I bolded the part that is problematic. How does one burn a key into the device as part of a driver, exactly? With security, the devil is in the details, and your proposed system sounds no better than similar systems which have failed in the past.
That you are too dumb to understand an idea doesn't mean the idea is dumb.
Nice ad hominem, but maybe you should have provided a substantive argument instead.
I believe your explanation rather than my intelligence is at fault here. You identify two systems as functional examples of your new "security" feature---neither of which is effective in practice. AACS has been compromised repeatedly, which shows that simply revoking the exposed keys and hoping new equipment fares better is not an effective strategy.
Can you explain, clearly, how your system differs in such a way as to render it immune to similar attacks? If not, then there is absolutely no reason to take your proposal seriously.
Yes. Is that a problem?
If you don't see a problem with PRIVATE KEYS being distributed inside mass-produced hardware, I do not even know where to begin criticizing your position.
Every piece of equipment would need significant anti-tampering measures because as soon as the keys are retrieved from one device, it is game over.
This is why DRM software keeps getting cracked over and over in spite of the billions of dollars being spent on developing it. If your scheme requires a secret that the user needs to operate the device, it will be compromised.
People crack stuff like this for fun. We've seen it happen year after year. Do you think there will be more or less cracking attempts when there are serious espionage or financial incentives?
To be an HID, it must announce itself as one (called "driver" even when it just announces itself and requests the default OS driver). To do so, it must authenticate with the host OS. If not, the HID functionality will be disabled.
What? USB devices in general, and HIDs in particular, do not authenticate with the OS when plugged in.
You plug it in, and it negotiates with the host controller automatically. The host controller notifies the OS that the device is there, and then the OS queries the device for its properties. The device is perfectly capable of lying about what it is and what it does.
If the device identifies as a keyboard, mouse, Smart Card reader, or removable storage, by default the OS will load its native drivers and handle the device seamlessly. The device could have nefarious functionality, but the OS has no way of knowing about that.
Various OS security tools and third-party utilities can attempt to restrict the use of USB devices. None of them are pleasant to use---from the standpoint of either the administrator or the end user.
I've been told the problem is when the USB drive is actually a storage device, but leaches power (but no connectivity to the host computer) to broadcast the contents of the device on WiFi to a listening attack machine outside (but in WiFi range).
Not terribly practical or interesting. This idea probably came from someone who watches too many "hacker" movies. Anyone who is concerned about restricting USB devices probably already has a solution for detecting rogue Wifi clients and APs. If not, they can buy one off the shelf. This is something I would expect to see in a Hollywood movie.
Rogue USB devices are not something a hacker is going to use against some random citizen in hopes of scoring access to their checking account. This is something enterprises and governments are going to be worried about, and they have options for mitigating the threat.
Storing authentication credentials in a retrievable form anywhere is stupid, even in memory. Kerberos has been around for decades, and it eliminates the need for a password to exist in memory as soon as it is hashed.
If Kerberos is not practical for a particular application, the same principles can be used in proprietary authentication mechanisms.
A plaintext password should never persist. Period. It is the result of a stupid decision somewhere, and we have known better for a long, long time.
Your theoretically sound system is not practical to implement. Plus, we already have a better solution.
The only problem you've clearly identified with the CA system is already addressed by certificate pinning. Your solution offers nothing of value beyond what I can accomplish with pinning---and your idea brings a whole lot of administrative overhead.
While certificate pinning does require local administration, it is significantly less burdensome than your approach. Even Microsoft supports it now, so it is not some niche security option anymore.
Certificate pinning takes ultimate trust back from the CAs yet works easily with the existing infrastructure for applications that you don't need to control as tightly. I have no idea why you are promoting a system that is more complicated and less compatible with no concrete advantages.
Yes, the lack of a theoretically sound system is a problem. Your "solution" was to disband the existing system without any sort of meaningful replacement.
We can always use PGP/PKI internally and with close associates. But we need some form of identity verification for everyone else in the world too.
The CA system is flawed---but better than nothing at all. Your "solution" returns us to having nothing for the rest of the world. I.e., it is not a solution or an improvement in any meaningful way to what we already have.
So your suggestion is, let's keep all of our super important stuff on a front-end facing system in the first place.
I never said that, but thanks for throwing an asinine straw man up there.
They can probably lock things down better than they did, but I don't work at Sony and I haven't seen their network diagrams so I can't really say. But the idea of air-gapping financial systems for a company of Sony's size is mind-boggling stupid.
Even something as simple as warranty work breaks down without automation. Every authorized repair depot needs some way to order parts, submit claims, and receive payment at an absolute minimum. If you air-gap the systems for that, guess what happens to time and cost of warranty repairs? And this is just one facet of the business.
So right there, you have network-accessible procurement, payment, and personally-identifiable information (customer name/address and product serial number are typically included in warranty documentation). Waving the magical air-gap wand as a security fix means nothing if it fundamentally breaks the way the business operates.
So yes, Sony probably fucked up somewhere. If they're like most businesses, there are probably multiple problems with their infrastructure. But pretending there's a simple answer is just ignorant and does absolutely nothing to advance the discussion or solve any real-world problems.
If you air gap email and financial systems, you're stepping right back into the mid-1900s. Back when it took an entire office of secretaries to process correspondence, and another office full of accountants to handle billing and ledgers. Because if those systems are disconnected, someone will have to transfer reams of data in and out of them. That is no longer feasible.
Your suggestion is so completely impractical, I wonder why you joined slashdog in the first place. You clearly have no understanding of modern IT.
And your solution only works for entities with which you have a pre-established relationship and a shared secret (in this case, your personal information).
This does not solve the general problem of identifying an entity on the internet with whom you have no shared secrets.
This suggestion is nowhere near being a replacement for existing CAs as they are currently used.
If you actually read the article, you would see that they had administrative access to the zone files. Which means they could have changed whatever they wanted. They also had access to usernames and passwords, so hopefully no one used the same credentials elsewhere.
Get back to us when you pull that off with whois.
Pretty sure he's going off what was disclosed on the "Have you ever been convicted... ?" section of the job application.
Since non-disparagement clauses are almost exclusively used in severance agreements, there is a disparity in power that makes them practically coercive. I have no problem condemning them in that context.
You seem to be confusing a few things here, though. True statements can be disparaging in nature. Google it if you're inclined to argue because it's rather cut-and-dried---and not worth arguing over.
And no, they do not have to specify what you cannot speak about. If the severance agreement prohibits disparaging statements, it's pretty much carte blanche for legal action if you say anything bad about them. They may not choose to file suit for something as simple as saying, "XYZ Company sucks!"---but they could. You're free to walk away without a severance package if you don't like their terms. Most companies are not willing to negotiate the matter with someone they are in the process of terminating.
Should you happen to disparage the company after signing a typical severance agreement, they can sue for the severance pay and possibly even the cost of benefits during the severance period (if they continued your benefits, of course). They may also be able to recoup their legal fees.
I have seen a lot of people in that situation, and a cavalier attitude never ended well. Unless the employer actually breaks a law, the asymmetry of power is simply too great.