Is that you, Steve Gibson?
I read an article on this recently, it appears that Target contacted both those whose name/address/email had been compromised AND those who use their credit card there during the time period using the same email. They should have split the two.
So it's likely that your personal information was compromised, but not your credit card number. Be on the lookout for phishing attempts.
So, time for me to rant, but on-topic, for a second.
Everybody knows, I would hope, that best practice is to never allow an Internet-facing server to initiate outbound traffic. This is both because, should the server get compromised, it becomes a new attack vector - as in Code Red or SQL Slammer. This is also because, as in Target's case, it makes it fairly trivial to exfiltrate stolen data.
But services still persist that require that this very access be enabled. My current case in point: ReCAPTCHA. Google hosts the URL for this service, intended to provide additional security, on a www.google.com URL, which means that, at minimum, I have to allow outbound access from any server hosting a ReCAPTCHA on port 443 to everything Google owns. In practice, of course, it's all but impossible to keep track of Google's address space for firewall purposes, so this means that I have to allow that server out on port 443 to the entire Internet. It's either that, or set up a proxy solution that can do URL filtering and then require the CAPTCHA verification code to use that. Not exactly something your typical smaller company using ReCAPTCHA is apt to do.
I've talked to competing, for-pay, services, and they require the same thing, despite the fact that they're smaller and have only a few, well-defined networks, but they won't commit to keeping me up-to-date with network changes.
We really need to start pushing back on this crap. Servers accepting inbound traffic should never need to initiate outbound communications.
It would probably be a good idea to take installation media along with you, and make sure to hash it before you go, then keep the hash on your person. If my machine got grabbed for "inspection", I wouldn't trust the OS on it as far as I could throw it.
And I would also argue that The Forever War should be in the list somewhere above Card's book.
Heck, between the RPV's and the children, I'm almost hesitant to even call it a "military" book per se.
If the data is that confidential, you should probably look into an actual FIPS-certified network-connected HSM instead of rolling your own.
I did a project a few years back using nCipher NetHSMs (they've since been bought up, I believe) and they were quite cool technology. Even then, I think one of these devices was in the $25K range at most.
The great thing is, if you generate a key pair with one of these, you literally cannot get access to the private key to hand over to the government, even if you wanted to.
Actual answer: no.
The CSR (Certificate Signing Request) contains only the public half of the key, to be signed by the CA's key which results in the CA attesting that the information is verified.
The entity whose key was signed always maintains control of the private key. Which, to me, is the reason that public-key encryption is not "over". The NSA would have to strong-arm every single holder of an SSL key, not just the Certificate Authorities.
Granted, though, those private keys are not often held terribly securely - they're most often just files on a server that aren't even password-protected, because that requires an admin to type in passwords whenever the Web server is restarted. They COULD be held in an HSM, a hardware security module much like a TPM on steroids, but that's very expensive and difficult to set up.
However, none of this means that public-key crypto is broken. It's possible that individual sites could be compromised via this route (Facebook, Google, etc) but as a whole, no.
The hardware isn't from Icom, it's from DVSI and available, at least on paper, to anybody that wants to pony up for a pre-programmed DSP from them. The existence of the DV Dongle from Internet Labs completely disproves your statement.
Now, as I've previously posted, I don't like that it's a proprietary codec that is only implemented in hardware, but that doesn't mean "you need to buy decryption keys [...] from Icom". Let's keep this conversation factual, shall we?
Sadly, the protocol didn't allow for identifying the codec used for the voice bits, so even if one wasn't concerned about interoperability with normal DSTAR radios, it's not possible as the DSTAR radios will try (and fail) to decode the voice data that's encoded using Codec2, but try to decode it in AMBE.
I think we need a newer protocol anyway that is much more supportive of mixed voice and data comms - the only way to send data with a DSTAR handheld is by keying up voice, wasting most of the bits, and sending slow-speed data along with the voice bits. It's really tragic if you ask me, such a waste.
Not possible to do in software because the only implementation is in a DSP chip that must be purchased from the vendor.
I have much less problem with the use of a proprietary codec (although I do wish Codec2 had been available at the time or a good allowance was made in the protocol for changing codecs) than I do with the fact that the only implementation possible is in hardware. It very much limits flexibility in open-hardware and computer-based implementations relating to the protocol. Such a waste.
People keep wishing that other manufactures would implement DSTAR hardware - I hope they don't, as I'd like to see it replaced with something much more open, or at least flexible. As well, support for data transmissions was implemented very badly and IMHO as implemented it's a waste of bandwidth, because it should have much better data transmission support.
Um, actually, Jared A. Bruegman, ex-KC0IQN, of Bolivar, Missouri, was given a $10,000 Notice of Apparent Liability (NAL, FCC-speak for "you've been a bad boy, pay up") just a couple of months ago.
No kidding. I consulted for a few days in Batesville, Indiana a few years back, and flew into (and out of) Cincinnatti, which was on DST while eastern Indiana was not. Luckily I left quite early for the trip back home, because I lost an hour on the drive! Easily could have missed my flight because of all this stupidity.
Count me in for completely getting rid of this madness. Crossing time zones I can keep track of, but not taking into account the fact that only half of one state doesn't feel like following the rules.
We just made changes to every system not so long ago when Bush decided to lengthen DST, and I don't recall the world ending. Now is a great time to do it while the experience is still fresh.
Or they did as of not very long ago at all - I had to recover my password on their site, and just about fell out of my chair when, instead of sending me a recovery link, they emailed me my current password.
Nowadays that password is a KeePass-generated random one.
Not a lot of change that I can see.
With IPv6, the smallest subnet that will be assigned is a
So, many, if not most, hosts nowadays choose a random value for their host ID, do the IPv6 equivalent of a gratuitous ARP to make sure it's not in use already (highly unlikely), and if not they use it. Many also change their address periodically by doing this again.
Nice advantage here: unless a given network is using DHCPv6 and logging the requests, this is all done on-the-fly with no logging and no discovery possible.