Comment Re:Can we stop using the word 'TAPE' (Score 1) 643
Yes, wireless network security, network service security, and wireless data coverage are all solid enough that this is a great idea and definitely could not be easily hacked.
Yes, wireless network security, network service security, and wireless data coverage are all solid enough that this is a great idea and definitely could not be easily hacked.
Hardcoded credentials aren't necessary. What they *mean* is that the *reason* for hardcoded credentials is "support". "Necessary" here doesn't actually mean "necessary", but rather, "deemed to be the best choice". Of course, it might really be the best choice. There's certainly a cost associated with making the support more complicated. You have to weigh that against the difficulty of using the hardcoded credentials and what you can do with them. There are lots of potential tradeoff points, from "using hardcoded credentials was the stupidest choice you've ever made" to "it's technically offensive, but also the best option".
Doesn't require physical access. Firmware reprogramming is easily over-the-wire with many USB devices. It just requires logical access to the device. A computer running malware is a malicious third party with logical access to the USB device.
Yes, devices have updateable firmware. How is this a "sneakernet issue"? The firmware update does not cause Windows to install anything. Those are orthogonal features.
Sure. Depending on your device (iPhone works differently from the standard USB fast-charging spec), you should be able to easily look up what resistors need to go where. (As mentioned, non-iPhone devices use an informal standardized spec. A circuit diagram of something like a Samsung charger should show you.)
What sneakernet issue? Be more clear. USB devices do not contain installable software, except for the obvious and well-known case of a mass-storage device happening to contain files that can be intentionally or inadvertently executed by the end user after the MSD is connected.
You just need a resistor or two. Almost any USB-charged device will charge at 500 mA if it is connected to a dumb charger (no data lines), but in order to charge at a higher current (as many devices do), it needs to sense that it's connected to a charger that supports the higher current draw. So that it can be implemented without real USB-supporting electronics, that's just done with some simple electrical components. So you can make a charger that blocks the data lines but permits full-speed charging.
If you're okay with the slow version, just go out and buy a "power only" USB cable. They already exist. Alternately, this.
It'd probably be easier to implement a little hardware device that places restrictions on device classes that can connect through it and limits hybrid devices (e.g., keyboard+mouse = ok, keyboard+webcam = reject).
A couple NSA letters later and MS is now sending NSA payloads.
Because they couldn't already do this with network-distributed software updates?
1. A ton of USB devices are actually implemented as general-purpose components with programmable firmware (attached to whatever support hardware, like a network card or a webcam, is necessary). So they're more common than you think.
2. Smartphones are an excellent reprogrammable USB device that lots of individuals have.
3. This is difficult enough to really engineer well that it is probably a bigger threat as a targeted attack against a big organization for now. Until someone does the engineering to make it easy to deploy widely. Then, it'll be a threat for everyone. Kind of like automated hacking of consumer-grade routers to modify the firmware to participate in an Internet-wide portscan. It's the Metasploit effect: it's not a big problem until someone makes it automated, then it is.
The whole point of this is that the malware reprograms the firmware of existing, trusted devices to make them malicious.
None. Now you've identified and understand the problem.
They are bugged only once, and then they accept the cert locally.
Not necessarily. On Chrome, for example, accepting a self-signed cert long-term isn't the default behavior. Even that isn't a great idea: you have no knowledge of whether the self-signed cert is legitimate or not without a substantial out-of-band communication of technical information to nontechnical people, which isn't cheap. A college network is a good example: it should be treated as a hostile network, so MitM against a self-signed cert within your private network is very much a reality.
Or the college provides an easy way for the BYOD people to acquire the college's cert.
Doing that at a large scale for technically-inclined people costs more than a public CA cert. Once you have to support regular users, it's way more expensive.
There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2
Certs don't include IP address. When you get a cert for server1.internal.unm.edu, they don't know what IP address(es) it will be bound to, and they don't and shouldn't care.
No need whatsoever.
There certainly is a need. It's to enable devices that want SSL but aren't configured to trust your internal CA to securely identify your server. There are lots of reasons for "aren't configured to trust your internal CA" to happen.
And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
They're going to require that certs they issue are for domains that are tied to an external domain. For example, mail.internal.unm,edu. This doesn't negatively impact people's ability to have public CA certs for internal resources. Nor should it.
Judging by how the police actually operate, a hard drive with that data will be put in a box and put into storage with a large collection of other such boxes, probably never to be seen again.
Oddly, it's not. That's where OP is coming from. "Treasure trove" comes ultimately from Latin via French (or at least, some language fragments the Normans brought over). The "trove" means "found", so it's "found treasure". That's why in the original (pre-English) phrase, the word order is backwards: "trove" is the adjective, "treasure" is the noun, and it follows the appropriate French/Latin word order. It was pulled directly into English without reordering (common for borrowed phrases). Eventually, "trove" (which had no English meaning at all) became a synonym (a shortening) for "treasure trove".
So by etymology, "trove" was originally an adjective. However, it means nothing in English. The phrase "treasure trove" is a noun phrase all by itself that can't really be broken into parts.
With your bare hands?!?