Oh, I'd be the first to agree that colleges are damned expensive, sufficiently so that most people's access to them is largely an economic question. That much is indisputable.
However, the fact that "many people can afford to pay little or nothing for those aspects of college that don't make purely financial sense", which is unquestionably true, does not imply that those aspects don't exist, just that people can't afford them.
I suspect that the first question falls into the "Very interesting, pity we'll never find out..." category.
As for the second, I suspect that it is largely a matter of manufacturing convenience and/or fob tamper resistance. With RSA doing the keyfill at point of manufacture, the customer just needs to load the seed file for the entire batch onto their authentication server and then hand out the tokens, which are glued shut with considerable enthusiasm, and have no externally accessible electrical connections of any sort. If the customer did the fill, that would be extra effort (and a step where grunt manual labor would meet very sensitive data, not a pleasant HR situation...) for them, and would mean that RSA would have to validate their design against attacks on the exposed connectors. Neither is impossible to overcome; but under the(now invalid) assumption that RSA wouldn't fuck it up, certainly easier to avoid than to deal with.
If they need to check the list of seeds they've already used, their seed length is arguably way, way, way too short. With sufficient seed length, the risk isn't quite zero; but it is so vanishly close that it doesn't matter.
Since the algorithm that the tokens use is public knowledge, anybody can, for a given seed, compute the token display value at time T. If the seed-space were so small that RSA needed to do duplicate checks, rather than just resting assured in the fact that they'd need to issue a fob to every proton in the universe before the risk of duplication rises above 1%, then there would be the theoretical danger that an attacker could just brute-force things by computing each seed chain, and then inferring the target fob's seed by sampling its output at one or more times and seeing which seed chain it matched...
RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...
My main issue was with retaining the seed keys in any network accessible location.
Those things should have been deleted upon transfer to the customer or(if so requested) stored on archival media in a vault somewhere unless needed by the customer for recovery purposes.
My point isn't "Ha Ha, their network guys fucked up, I could have done better!" My point is "for something as interesting as the seeds you would find useful in compromising a laundry-list of high-profile, high-security targets, basically no configuration would be sufficiently secure, and storing them in an insufficiently secure manner is hugely irresponsible.
After the the tokens were seeded, there was no further need for RSA to have them anywhere that they could be accessed electronically.
Are there any big, important checkbox-compliant certifications that RSA's customers might have been using the (Not Cheap) RSA tokens to obtain that, as a consequence of this sordid episode, might no longer be attainable with RSA gear? That seems like it would be a fitting punishment for RSA's questionable security practices and even more questionable disclosure practices; but I'm afraid that I haven't wrapped my head around the alphabet soup of compliance acronyms in different areas enough to know.
Golly Shucks. As it turns out, maintaining a copy of the seed keys for devices we sold specifically as a high-security access control solution on our under-secured network might have been a less than totally good idea... Well, lessons learned, eh?
If one is feeling really serious, the so-called "data diode" devices can be used to ensure that the data to be analyzed goes out and nothing goes back in. Since they are sort of a niche market, and the problem of making anything remotely resembling a normal network protocol work unidirectionally is a bit tricky, such hardware is Not Cheap; but neither is having hackers all up in your centrifuges...
At some point, unless Siemens has a very nasty legal trump card of some sort, they are going to have to adopt the "fuck it, better that the admins know." approach.
It isn't as though white hats have anything like a monopoly on security/penetration expertise in this world, and the word is already out about what device the vulnerabilities are in, and(since they are working on a new patch) that it exists in the latest available patch level. Presumably, any blackhats who care about access to such devices are already sniffing around. Also, with something like SCADA, where putting it on the public internet has always been seen as a bad idea, the "but if you release the information, even script kiddies will have a working attack toolkit" objection is arguably less serious. For internet-facing stuff, script kiddies with access to tools built by people smarter than they are are a serious hazard, as are low-rent cybercriminals looking for new bots and spam hosts and stuff.
For computationally limited and(hopefully) internal stuff, sophisticated attackers are a serious concern(since they are the ones most likely to perform a focused attack on the outer face of an organization, looking for holes that get them onto theoretically "internal" networks); but the noobs will hopefully never make it past the gates, and the spammers are unlikely to have an economic incentive to compromise something that makes a lousy bot. If the vendor can't get their act together, and fast, it quickly becomes more valuable for the admins to know, so that they can take appropriate measures at whatever points potentially link their internal and external networks.
The various fissures of Mt. Doom are SCADA controlled; but the consequences of merely possessing one of the interface controllers needed to communicate on the.. er.. somewhat sinister legacy ring bus that Sauron uses are so horrific that security through obscurity has proven more than adequate.
Does Mr. Beresford realize that, in the blasted wasteland that follows the fall of industrial civilization, pasty computer experts are relegated to the status of "slave" or "food source" by psychotic warlords wearing football/BDSM themed armor?
Make sure that Lord Humongous owes you some favors before Blackhat rolls around, everyone!
My understanding, from TFPR, is that the card does h.246 encoding onboard(and the manufacturer of the card has paid their protection money to the MPEG LA) so the driver has no h.246 related duties, it just configures the card and collects the encoded output.
Obviously, since the output is h.246, it'll need to be decoded for use, which does raise the patent issue; but not at the driver level.
The hilarious thing about conservapedia's relationship with relativity is that they can't quite decide whether they hate it because it is dirty, unchristian jew-physics that triumphed over good, solid, Newton, or whether they hate it because "relativity" is actually just pseudoscience that liberals use to justify "relativism"(yes, there are actually people who think that a bunch of equations covering some rather esoteric matters of physics are somehow a liberal plot to justify their lives of christian-bashing and hedonistic sodomy...)
I, for one, do not want to have to explain to some thugtastic DEA jackboots that "hash-based currency" can be acquired by legitimately doing a bunch of math, as well as by other means...
On the plus side, I'm pretty sure that 1984 didn't have versioning... It would, of course, be ideal for the correct writeup to always be on the default page; but editing is so much less sinister when changes never go down the memory hole...
I suspect that that is a perfect example of where the configuration complexity(for mass-market use) bites you. In an ideal world, a device like this doorbell would either talk directly to some cheap-n-cheerful SIP provider(if the only one of its kind in the house) or act as an internal extension with the ability to dial out, if one of a number of devices sharing the same numbers behind an Asterix box or other soft-PBX. Trouble is, unless you are a bit of a tinkerer, or some outfit decides to deliver an end-to-end-locked-to-them set-forget-and-pay-up appliance, the set of setup instructions implied by those statements is a touch alarming. Not totally hardcore, just read the wiki, man; but I'd pity the phone drone who has to run some n00b who calls his router "the internet" through it...
At least in the US, for quantity one,(unless you know some tricks, in which case I'd be delighted to hear) the minimum amount you end up paying just to keep a pay-as-you-go line open is, while rather less than a full contract line, often nontrivial.
For light users it is still the way to go; and I wouldn't be surprised if the terms for bulk/reseller integrated SIMs are rather better, but you can end up spending $50-$100 a year to keep the line open.
I agree that, for most purposes, a few extra normal characters are rather more useful than a few weird ones, and much less of a pain to type. Plus, if there are applications that hook in to wherever you have your fancy-unicode password that aren't expecting non-keyboard characters, fun ensues.
I really only mentioned it because it can be kind of a cute trick. A dash of Akkadian Cuneiform probably doesn't add too much more entropy than would the same number of keystrokes of normal alphanumeric; but it is more amusing, and tends to place your password entirely out of the scope of any commonly available precomputed tables.
The trend toward "every gadget with its own bloody cell contract" is rather annoying, especially when the house in which this item would be installed probably has a perfectly good internet connection already or, even if unwired, a number of devices that could be sharing the single comparatively expensive cellular modem and contract.
Unfortunately, home automation still seems to be in a rather ghastly state. You can get something polished if you pay reasonably serious money or sink considerable time and effort, and the options for cobbling stuff together out of miscellaneous geek gear are better than they used to be; but I do suspect that the rise of unnecessarily cell-driven widgets is (aside from the obvious rapacious greed of the telcos factor) driven by ease-of-use considerations. Embed a cell modem in something and, like magic, you don't have to pay support people to explain the mysteries of whatever horrid mixture of incompetence, cut-rate gear, and sheer mystery lies between the device they just purchased and the internet.
If you want to really spoil a hypothetical hash-cracker's day(and, depending on the keyboards you routinely deal with, often yours as well), you can take advantage of the fact that some systems(recent NT derivatives among them) will accept the assorted unicode characters not accessible on the keyboard of your language area.
It isn't fun to type; but "♯╪˧¾ᾥ▓►ﻸ" is relatively unlikely to fall easily. (Thanks Slashcode, still handling that Unicode, I see...)
As a true, red-blooded American I take pride in my nation's tough-on-crime policies of long sentences and harsh incarceration. It is simply unacceptable that some multinational research team of limp-wristed European eggheads is imposing tougher sentences on antiparticles than we are.
I, for one, will not be voting for anybody who can't promise that 25% of the world's antihydrogen will be doing 20-to-life in our very own 'SuperMax' high energy physics institutes.
Slashdot Mirror
Oh, I'd be the first to agree that colleges are damned expensive, sufficiently so that most people's access to them is largely an economic question. That much is indisputable.
However, the fact that "many people can afford to pay little or nothing for those aspects of college that don't make purely financial sense", which is unquestionably true, does not imply that those aspects don't exist, just that people can't afford them.
Arguably, treating college as 'purely economic' is the anti-intellectual part(or a sign that you experienced a shitty school...)
I suspect that the first question falls into the "Very interesting, pity we'll never find out..." category.
As for the second, I suspect that it is largely a matter of manufacturing convenience and/or fob tamper resistance. With RSA doing the keyfill at point of manufacture, the customer just needs to load the seed file for the entire batch onto their authentication server and then hand out the tokens, which are glued shut with considerable enthusiasm, and have no externally accessible electrical connections of any sort. If the customer did the fill, that would be extra effort (and a step where grunt manual labor would meet very sensitive data, not a pleasant HR situation...) for them, and would mean that RSA would have to validate their design against attacks on the exposed connectors. Neither is impossible to overcome; but under the(now invalid) assumption that RSA wouldn't fuck it up, certainly easier to avoid than to deal with.
If they need to check the list of seeds they've already used, their seed length is arguably way, way, way too short. With sufficient seed length, the risk isn't quite zero; but it is so vanishly close that it doesn't matter.
Since the algorithm that the tokens use is public knowledge, anybody can, for a given seed, compute the token display value at time T. If the seed-space were so small that RSA needed to do duplicate checks, rather than just resting assured in the fact that they'd need to issue a fob to every proton in the universe before the risk of duplication rises above 1%, then there would be the theoretical danger that an attacker could just brute-force things by computing each seed chain, and then inferring the target fob's seed by sampling its output at one or more times and seeing which seed chain it matched...
Dear customers who don't matter,
We are committed to providing you with a customer experience commesurate with what we can get away with. XOXOXO,
RSA
RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...
My main issue was with retaining the seed keys in any network accessible location.
Those things should have been deleted upon transfer to the customer or(if so requested) stored on archival media in a vault somewhere unless needed by the customer for recovery purposes.
My point isn't "Ha Ha, their network guys fucked up, I could have done better!" My point is "for something as interesting as the seeds you would find useful in compromising a laundry-list of high-profile, high-security targets, basically no configuration would be sufficiently secure, and storing them in an insufficiently secure manner is hugely irresponsible.
After the the tokens were seeded, there was no further need for RSA to have them anywhere that they could be accessed electronically.
Are there any big, important checkbox-compliant certifications that RSA's customers might have been using the (Not Cheap) RSA tokens to obtain that, as a consequence of this sordid episode, might no longer be attainable with RSA gear? That seems like it would be a fitting punishment for RSA's questionable security practices and even more questionable disclosure practices; but I'm afraid that I haven't wrapped my head around the alphabet soup of compliance acronyms in different areas enough to know.
Golly Shucks. As it turns out, maintaining a copy of the seed keys for devices we sold specifically as a high-security access control solution on our under-secured network might have been a less than totally good idea... Well, lessons learned, eh?
If one is feeling really serious, the so-called "data diode" devices can be used to ensure that the data to be analyzed goes out and nothing goes back in. Since they are sort of a niche market, and the problem of making anything remotely resembling a normal network protocol work unidirectionally is a bit tricky, such hardware is Not Cheap; but neither is having hackers all up in your centrifuges...
At some point, unless Siemens has a very nasty legal trump card of some sort, they are going to have to adopt the "fuck it, better that the admins know." approach.
It isn't as though white hats have anything like a monopoly on security/penetration expertise in this world, and the word is already out about what device the vulnerabilities are in, and(since they are working on a new patch) that it exists in the latest available patch level. Presumably, any blackhats who care about access to such devices are already sniffing around. Also, with something like SCADA, where putting it on the public internet has always been seen as a bad idea, the "but if you release the information, even script kiddies will have a working attack toolkit" objection is arguably less serious. For internet-facing stuff, script kiddies with access to tools built by people smarter than they are are a serious hazard, as are low-rent cybercriminals looking for new bots and spam hosts and stuff.
For computationally limited and(hopefully) internal stuff, sophisticated attackers are a serious concern(since they are the ones most likely to perform a focused attack on the outer face of an organization, looking for holes that get them onto theoretically "internal" networks); but the noobs will hopefully never make it past the gates, and the spammers are unlikely to have an economic incentive to compromise something that makes a lousy bot. If the vendor can't get their act together, and fast, it quickly becomes more valuable for the admins to know, so that they can take appropriate measures at whatever points potentially link their internal and external networks.
The various fissures of Mt. Doom are SCADA controlled; but the consequences of merely possessing one of the interface controllers needed to communicate on the.. er.. somewhat sinister legacy ring bus that Sauron uses are so horrific that security through obscurity has proven more than adequate.
Does Mr. Beresford realize that, in the blasted wasteland that follows the fall of industrial civilization, pasty computer experts are relegated to the status of "slave" or "food source" by psychotic warlords wearing football/BDSM themed armor?
Make sure that Lord Humongous owes you some favors before Blackhat rolls around, everyone!
My understanding, from TFPR, is that the card does h.246 encoding onboard(and the manufacturer of the card has paid their protection money to the MPEG LA) so the driver has no h.246 related duties, it just configures the card and collects the encoded output.
Obviously, since the output is h.246, it'll need to be decoded for use, which does raise the patent issue; but not at the driver level.
The hilarious thing about conservapedia's relationship with relativity is that they can't quite decide whether they hate it because it is dirty, unchristian jew-physics that triumphed over good, solid, Newton, or whether they hate it because "relativity" is actually just pseudoscience that liberals use to justify "relativism"(yes, there are actually people who think that a bunch of equations covering some rather esoteric matters of physics are somehow a liberal plot to justify their lives of christian-bashing and hedonistic sodomy...)
I, for one, do not want to have to explain to some thugtastic DEA jackboots that "hash-based currency" can be acquired by legitimately doing a bunch of math, as well as by other means...
Impressive, most impressive, given that the constitution wouldn't exist for a substantial period of time thereafter...
I think my favorite example of just how far off the rails they are has got to be their "Conservative Bible Project".
On the plus side, I'm pretty sure that 1984 didn't have versioning... It would, of course, be ideal for the correct writeup to always be on the default page; but editing is so much less sinister when changes never go down the memory hole...
Don't they know that Conservapedia is their home on the internet, free of the lies and corruption of the liberal filth?
I suspect that that is a perfect example of where the configuration complexity(for mass-market use) bites you. In an ideal world, a device like this doorbell would either talk directly to some cheap-n-cheerful SIP provider(if the only one of its kind in the house) or act as an internal extension with the ability to dial out, if one of a number of devices sharing the same numbers behind an Asterix box or other soft-PBX. Trouble is, unless you are a bit of a tinkerer, or some outfit decides to deliver an end-to-end-locked-to-them set-forget-and-pay-up appliance, the set of setup instructions implied by those statements is a touch alarming. Not totally hardcore, just read the wiki, man; but I'd pity the phone drone who has to run some n00b who calls his router "the internet" through it...
At least in the US, for quantity one,(unless you know some tricks, in which case I'd be delighted to hear) the minimum amount you end up paying just to keep a pay-as-you-go line open is, while rather less than a full contract line, often nontrivial.
For light users it is still the way to go; and I wouldn't be surprised if the terms for bulk/reseller integrated SIMs are rather better, but you can end up spending $50-$100 a year to keep the line open.
I agree that, for most purposes, a few extra normal characters are rather more useful than a few weird ones, and much less of a pain to type. Plus, if there are applications that hook in to wherever you have your fancy-unicode password that aren't expecting non-keyboard characters, fun ensues.
I really only mentioned it because it can be kind of a cute trick. A dash of Akkadian Cuneiform probably doesn't add too much more entropy than would the same number of keystrokes of normal alphanumeric; but it is more amusing, and tends to place your password entirely out of the scope of any commonly available precomputed tables.
The trend toward "every gadget with its own bloody cell contract" is rather annoying, especially when the house in which this item would be installed probably has a perfectly good internet connection already or, even if unwired, a number of devices that could be sharing the single comparatively expensive cellular modem and contract.
Unfortunately, home automation still seems to be in a rather ghastly state. You can get something polished if you pay reasonably serious money or sink considerable time and effort, and the options for cobbling stuff together out of miscellaneous geek gear are better than they used to be; but I do suspect that the rise of unnecessarily cell-driven widgets is (aside from the obvious rapacious greed of the telcos factor) driven by ease-of-use considerations. Embed a cell modem in something and, like magic, you don't have to pay support people to explain the mysteries of whatever horrid mixture of incompetence, cut-rate gear, and sheer mystery lies between the device they just purchased and the internet.
If you want to really spoil a hypothetical hash-cracker's day(and, depending on the keyboards you routinely deal with, often yours as well), you can take advantage of the fact that some systems(recent NT derivatives among them) will accept the assorted unicode characters not accessible on the keyboard of your language area.
It isn't fun to type; but "♯╪˧¾ᾥ▓►ﻸ" is relatively unlikely to fall easily. (Thanks Slashcode, still handling that Unicode, I see...)
As a true, red-blooded American I take pride in my nation's tough-on-crime policies of long sentences and harsh incarceration. It is simply unacceptable that some multinational research team of limp-wristed European eggheads is imposing tougher sentences on antiparticles than we are.
I, for one, will not be voting for anybody who can't promise that 25% of the world's antihydrogen will be doing 20-to-life in our very own 'SuperMax' high energy physics institutes.