we all can write the headline and article now for going the other direction the day some cloud provider implodes: Company Widgetcorp declared bankruptcy today. Their tragic fall from stalwart Rusell-2000 midcap manufacturer to receivership happened unexpectedly: Their cloud-based XXX provider shut off servers without warning less than 60 days ago, and Widgetcorp was never able to recover critical processes and data.
Perhaps the "use the cloud as your DR target" model is a good one after all! I think a good way for enterprises to hedge their bets and keep their cloud implementations nimble, is to set up 2 of them.
Hear me out.
You buy 2 separate cloud services from 2 different vendors. You treat the second cloud service exactly as the GP comment suggested you treat the first one during your initial migration; duplicate all the servers, make sure the apps work, keep the data synced with the first one via whatever mechanism makes sense for your applications, and then it can function as a hot standby. Per the usual 'cloud' billing parameters, you pay very little in CPU time, only the bandwidth required to keep the data synced - which you would have had to pay for offsite DR anyway. Additionally, having to maintain the same site set up in 2 different cloud providers, while irritating to your developers, is great discipline to ensure that subsequent versions won't force you to be married to one particular cloud implementation.
Sites which you can pluck off of one provider and dump onto another with minimal reengineering are desirable for myriad reasons. And if you're going to go to the trouble of designing it like that, you might as well take that one extra step and deploy it twice.
Yeah, here I'm talking specifically about someone who already knows something about your password system.
Someone who administrates one other site for which you generated a password by this method would have to have asked some questions (or, say, overheard you talking about your password system on Slashdot) in order to know in the first place that the password should be decomposed into three separate tokens and then recombined, in any of n possible ways - as i suggested, probably several dozen.
Once they know this, however, they have n possible candidates for the original 3 strings, and n different ways of recombining them, yielding an effective keyspace of n^2. Pretty paltry.
And two (or more) site administrators working in collusion, having access to two of your passwords, wouldn't even need to overhear you explaining your password system in order to attack it; the system and your original 3 strings would be nearly self-evident from looking at the passwords themselves.
The attacker doesn't have even partial information with which to compute Bayesian statistics.
Did you miss the part where I said
when you know one of someone's other passwords
?
We are talking about somebody, perhaps the administrators of 2 other sites you use in collusion, who knows at least one of your previous password choices. Just like the zip compressor knows the content of the preceding part of the string.
The reason password reuse is a problem, really boils down to the fact that the concatenation of any two of your passwords should contain significantly more entropy than either password alone. Direct password reuse reuse fails this test horribly; reordering it in large chunks is better, but not by much.
Password strength can only be measured relative to the information already available to the hypothetical attacker. If there's a stickynote on your desk with that exact string on it, then assuming the attacker can read it, the long password is about as strong as the short one. The whole text of the note, and then all obvious abbreviations and permutations of it, should be searched long before you've exhausted the space of 10-char strings.
Anyone hoping that the attacker will not incorporate that information into his search just because it happens to read like a plausible-sounding office reminder,is relying on a form of security through obscurity.
Entropy is a property of the probability distribution from which a sample (i.e., a password) is drawn. Whether or not reusing a string adds entropy depends on the underlying distribution.
The probability distribution is radically changed when you know one of someone's other passwords. Just like the probability of encountering the three-byte sequence "the" is radically changed after you've found it once in a string.
Maybe the trick is to do something like "Your password is unacceptable because it can be broken down into 2 substrings both of which get more than 50,000 Google hits."
There are on the order of several dozen intuitive ways to combine 3 strings of 8 characters. So yes, there are about as many generatable passwords in your method as there are possible values for 1 character.
Y'see, reusing a string does not significantly add entropy. That is why zip compression works.
And, all other things being equal, this rule would be broken once out of every 26^3 days (or whatever Enigma's keyspace was). Going from that probability to guaranteeing that it won't adds virtually no information at all.
Nonetheless, I bet yesterday's key was always one of the first keys they employed in the brute force attack, because they knew that catching some scatterbrained radio operator forgetting to reset his cipher was far more likely than naturally producing the same key two days in a row in an uncompromised random system.
My problem with the xkcd scheme is that users are lazy and rather than pick 4 random words, they'll pick 4 words that are easy to remember in sequence: "haveityourway" "darksideofthemoon" "thesearenothtedroidsyourelookingfor", so with a phrase dictionary and some grammar rules, you still have a good chance at brute-forcing some user's passwords.
You could perform this attack using Google's autocompletion database as a dictionary.
I doubt that he takes care of the fact that this is words vs random characters.
Yes, he does.
Just a question: Do you actually understand what is meant by those "bits of entropy" tallies that he's counting using rows of squares? If you don't know about http://en.wikipedia.org/wiki/Shannon_entropy then you're ill equipped to understand what this comic is trying to say.
But for broadcasters and advertisers, it is an attack on an entrenched television business model, and it must be strangled, lest it spread elsewhere.
Or, lest it make digital TV and PVRs finally offer a user experience that approaches being competitive with, say, BitTorrent. It's funny that their business model depends upon making their customer happy - but not too happy.
Buy an LCD TV (or repurpose the one you probably already own). Buy or build a wall mount. Buy a Raspberry Pi for less than 30 bucks. Plug in a keyboard. Spend half an hour setting up and testing a startup script to start a Skype instance on boot. Unplug the keyboard. Done.
Um, that's not what hyphenated ideology names mean. Would you say the "Marxist-Leninist Party" in Canada http://www.mlpc.ca/ has done so little research that they think Leninism = Marxism? Or do you think maybe they were trying to name a hybrid philosophy which is not adequately captured by either -ism on its own?
If you've flipped past Fox News at any point in the past 5 years or so, you can not have missed the millions of self-identified "Libertarians" whose talking points sound more like John Galt than Nozick. You've seen those, right?
Slashdot Mirror
we all can write the headline and article now for going the other direction the day some cloud provider implodes: Company Widgetcorp declared bankruptcy today. Their tragic fall from stalwart Rusell-2000 midcap manufacturer to receivership happened unexpectedly: Their cloud-based XXX provider shut off servers without warning less than 60 days ago, and Widgetcorp was never able to recover critical processes and data.
Perhaps the "use the cloud as your DR target" model is a good one after all! I think a good way for enterprises to hedge their bets and keep their cloud implementations nimble, is to set up 2 of them.
Hear me out.
You buy 2 separate cloud services from 2 different vendors. You treat the second cloud service exactly as the GP comment suggested you treat the first one during your initial migration; duplicate all the servers, make sure the apps work, keep the data synced with the first one via whatever mechanism makes sense for your applications, and then it can function as a hot standby. Per the usual 'cloud' billing parameters, you pay very little in CPU time, only the bandwidth required to keep the data synced - which you would have had to pay for offsite DR anyway. Additionally, having to maintain the same site set up in 2 different cloud providers, while irritating to your developers, is great discipline to ensure that subsequent versions won't force you to be married to one particular cloud implementation.
Sites which you can pluck off of one provider and dump onto another with minimal reengineering are desirable for myriad reasons. And if you're going to go to the trouble of designing it like that, you might as well take that one extra step and deploy it twice.
Oh, I get it! You're talking about collisions!
Did You Know that Chuck Norris is kind of a regressive homophobic dick?
It's a Fact®.
Yeah, here I'm talking specifically about someone who already knows something about your password system.
Someone who administrates one other site for which you generated a password by this method would have to have asked some questions (or, say, overheard you talking about your password system on Slashdot) in order to know in the first place that the password should be decomposed into three separate tokens and then recombined, in any of n possible ways - as i suggested, probably several dozen.
Once they know this, however, they have n possible candidates for the original 3 strings, and n different ways of recombining them, yielding an effective keyspace of n^2. Pretty paltry.
And two (or more) site administrators working in collusion, having access to two of your passwords, wouldn't even need to overhear you explaining your password system in order to attack it; the system and your original 3 strings would be nearly self-evident from looking at the passwords themselves.
common substitutions make the password exponentially harder to crack
each one doubles the effective keyspace.
Successive doubling is an example of
wait for it
exponential growth
Did you miss the part where I said
?
We are talking about somebody, perhaps the administrators of 2 other sites you use in collusion, who knows at least one of your previous password choices. Just like the zip compressor knows the content of the preceding part of the string.
The reason password reuse is a problem, really boils down to the fact that the concatenation of any two of your passwords should contain significantly more entropy than either password alone. Direct password reuse reuse fails this test horribly; reordering it in large chunks is better, but not by much.
Password strength can only be measured relative to the information already available to the hypothetical attacker. If there's a stickynote on your desk with that exact string on it, then assuming the attacker can read it, the long password is about as strong as the short one. The whole text of the note, and then all obvious abbreviations and permutations of it, should be searched long before you've exhausted the space of 10-char strings.
Anyone hoping that the attacker will not incorporate that information into his search just because it happens to read like a plausible-sounding office reminder,is relying on a form of security through obscurity.
For having to remember something additional about your password you want more than a bit of entropy.
Ok, but even if it does add only a bit, that still meets the definition of "exponential". /pedant
Entropy is a property of the probability distribution from which a sample (i.e., a password) is drawn. Whether or not reusing a string adds entropy depends on the underlying distribution.
The probability distribution is radically changed when you know one of someone's other passwords. Just like the probability of encountering the three-byte sequence "the" is radically changed after you've found it once in a string.
Sorry, Golddess. I didn't read usernames so closely - obviously that wasn't your method.
Maybe the trick is to do something like "Your password is unacceptable because it can be broken down into 2 substrings both of which get more than 50,000 Google hits."
There are on the order of several dozen intuitive ways to combine 3 strings of 8 characters. So yes, there are about as many generatable passwords in your method as there are possible values for 1 character.
Y'see, reusing a string does not significantly add entropy. That is why zip compression works.
the key was different than yesterday
And, all other things being equal, this rule would be broken once out of every 26^3 days (or whatever Enigma's keyspace was). Going from that probability to guaranteeing that it won't adds virtually no information at all.
Nonetheless, I bet yesterday's key was always one of the first keys they employed in the brute force attack, because they knew that catching some scatterbrained radio operator forgetting to reset his cipher was far more likely than naturally producing the same key two days in a row in an uncompromised random system.
Even worse, some websites truncate the password silently and just hash the first n characters. Which is horrible.
Why exactly do you think 'entropy' is the wrong word? It's a pretty well-formed concept in information theory.
My problem with the xkcd scheme is that users are lazy and rather than pick 4 random words, they'll pick 4 words that are easy to remember in sequence: "haveityourway" "darksideofthemoon" "thesearenothtedroidsyourelookingfor", so with a phrase dictionary and some grammar rules, you still have a good chance at brute-forcing some user's passwords.
You could perform this attack using Google's autocompletion database as a dictionary.
I doubt that he takes care of the fact that this is words vs random characters.
Yes, he does.
Just a question: Do you actually understand what is meant by those "bits of entropy" tallies that he's counting using rows of squares? If you don't know about http://en.wikipedia.org/wiki/Shannon_entropy then you're ill equipped to understand what this comic is trying to say.
No, it would be "weaker by half" if the alternative was a single capital letter at the beginning of the password.
In fact, the alternative is that any, some, or all of the 28 characters could be capitalized or not.
So the first character halves the password's strength if it is predictably lower-case.
and the second halves it again.
and so does the third.
Incidentally, halving or doubling the key space is not "a lot," not by any cryptologist's standards.
Sure, its 28 characters, but its still lowercase only.
That makes it a lot weaker, no?
It makes it weaker by a factor of about 2^28.
Which sounds like a lot, but when the lowercase password space is already 26^28, it's not much.
XKCD's math is sound.
I find it amusing that anyone who would pay that for a watch could be bothered spending mental energy on anything as piddling as a shipping fee.
And they even get the "product" to pay them for the privilege of being sold.
Pretty sweet deal.
Or, lest it make digital TV and PVRs finally offer a user experience that approaches being competitive with, say, BitTorrent.
It's funny that their business model depends upon making their customer happy - but not too happy.
Buy an LCD TV (or repurpose the one you probably already own). Buy or build a wall mount.
Buy a Raspberry Pi for less than 30 bucks.
Plug in a keyboard.
Spend half an hour setting up and testing a startup script to start a Skype instance on boot.
Unplug the keyboard.
Done.
The legitimacy of government derives from the consent of the governed. I believe in rough consensus and running code.
Um, that's not what hyphenated ideology names mean. Would you say the "Marxist-Leninist Party" in Canada http://www.mlpc.ca/ has done so little research that they think Leninism = Marxism? Or do you think maybe they were trying to name a hybrid philosophy which is not adequately captured by either -ism on its own?
If you've flipped past Fox News at any point in the past 5 years or so, you can not have missed the millions of self-identified "Libertarians" whose talking points sound more like John Galt than Nozick. You've seen those, right?