Oh for fuck's sake. I hope Ars screwed up that email address. Sometimes I feel like regulatory capture has totally screwed our national defense.
I'm from Maryland. I know a lot of defense/NSA people. Some are fantastic. Others... let's just say not everybody is the best and brightest.
" Congratulations gentleman - you're everything we've
come to expect from years of Government training."
-- Zed, in "Men in Black"
Shorter lived keys and more frequent updates, provided you also have a secure way of authenticating the updates (hard) is often preferred.
Adding auxiliary data (comparable to X509 certificate usage restrictions only for code-signing or signing for emails) would allow you to have a (central hardened) machine hand out certificates to your "semi trusted" administrators that only allow login from a specific IP-address, to a specific target-system, up to a certain date or even time. Putting this functionality in a script (to acquire the certificate and login to a system) such a wrapper could most likely be used as a drop-in replacement for the normal ssh-client.
If your restriction is to use only the default openssh already deployed to the target machines, one quick solution to hide the critical private key from the developer/admin/service machines would be to place it on a (hopefully somewhat hardened) machine running the ssh-agent, and access the agent by creative use of tunelling. In essence then the hardened machine would act as a kind of "smartcard" for all your admins.
Then you go fix your legacy firmware.
Private keys without a passphrase are probably even riskier than passwords
Private keys with a passphrase had better have a hard passphrase or they'll just be bruteforced offline
A quick sum of all the incidents in there adds up to 22 million health care records lost so far. It's hard to imagine the government could do much worse.
In case you don't feel like importing the CSV file somewhere, https://docs.google.com/spreadsheet/ccc?key=0AkJeZCqH2PsHdDZ...
(Not modified except for column width and a final tally)
http://www.healthit.gov/providers-professionals/health-infor...
As a "broadcast-emitting-messages-company" admin: would I really upgrade a system, which functionalities include complete take-over of my broadcast equipment, that is vulnerable to someone mistaking the private and public ssh keys of his "taking-over-any-equipment" equipment ?
I'd rather un-subscribe from that "service" in the limit of legality until that point of failure is fixed.
Every EAS receiver is typically monitoring other stations in the area for EAS relay. We actually have a tuner tuned to another station in the market and if we hear an EAS alert go across the air on their station we simply relay it. Due to the FM capture effect, it's _very_ easy to attack this channel; especially because there's _zero_ authentication on these incoming "relay" messages.
Even worse, some types of messages are setup for "national relay." This system was tested recently to ensure that a message could be relayed like this from one end of the country to the other -- and yes, it can. So, if you construct the right type of message, you can have it broadcast over _every_ station in america.
Relayed across radio stations, TV ticker, and your weather radio.
Here is a bit of the specification: https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding...