MatthewFickett wrote:This method is just intended to defeat case (2). In that situation, they don't even know that my passwords are derived from the site name - or anything. They look the same as the output of some SHA1-equipped script, for instance.
Yes, the "I'm relatively immune to attacks because I am so creative" defense.
This doesn't work.
Look, you aren't that creative. What you have thought of, so will many other people, at least slight variations thereof. About the only way to make your password generating algoirthm robust is to presume
that someone else gets ahold of your password generating algorithm algorithm, and from that they still won't be able to crack your password.
In your case, your password generating algorithm algorithm is "I thought it up, and thought it was neat" -- ie, something that (historically) has turned out to be cryptographically weak.
A strong way to generate a password generating algorithm is, as I have said, to generate on the order of 2^60 different password generating algorithms, all (or almost all) of which are "strong" and easy to remember, and then pick one at random and use that.
The weak point here -- how you generate the 2^60 password generating algorithms, your creativity -- is mitigated because it is then fed into a random number generator (hopefully a strong one), and a random result of your creativity is used. So even if they manage to figure out your "creative" tricks, because there are 2^60 different creative tricks you thought up, they still won't be able to crack your password.
I'm just anxious that they don't crack under attempts to, say, try all combinations of names and dictionary words, or normal letter-number-symbol substitutions. (I'm thinking of ones described in the other day's Ars Technica article ( arstechnica.com/security/2012/08/passwords-under-assault ) for instance).
You know the story of the army that was, at the start of each war, extremely well prepared to fight the last war they lost?
Dictionary words and generate-all-combination attacks are the last password war. Now attackers can build up huge databases of passwords generated by real people, and exploit the patterns that those people use in their passwords to generate password generators that match how people generate passwords.
Your mechanism -- a low entropy easily reversed password system on the url -- is a password that would be marginally stronger than typing "password" on every website against that kind of attack.
The "take a strong password, append the URL of the website, then put it through a strong hashing mechanism", on the other hand, defeats this kind of attack cold.
Certainly if someone knows I'm using a formula based on site name, it's a bit weaker.
No, it is not a "bit weaker". It is simply weak.
Certainly if someone knows both that and the kind of rules I use to generate the password, it's weaker still. But it doesn't seem sensible (to me) to assume that someone does know those things.
First, you just broadcast the fact that you generate passwords based on site names. And you did so in a way that you hoped to convince others. And others pointed out that they are already doing this.
So no, what you are doing is not rare -- but rather common. And as a common technique, people trying to crack passwords will be aware of it. So the security of your password should presume that people attacking it know the general technique you are using.
From that perspective, the password you generated for XKCD - d03#0) - doesn't seem like a particularly bad password. Unless a human is sitting down and looking at all my passwords, and trying to figure out what pattern I use, is there any reason to think this doesn't just look like a machine-generated random string?
First, as noted, as a randomly generated string, that pattern is weak. And letter-number patterns are pretty common, and something that is trivial for a cracking bot to learn when attacking a large password database, without a human involved.
It would take a pretty dumb password reversing algorithm to not notice the 3# and 0) pair. I mean, the same number twice, once with a shift key pressed? Pressing the shift key does not generate a lot of bits of entropy. To an inexperienced human, that might look random, but wouldn't to anyone who put much thought into it.
And that is the problem: you aren't going to be putting all that much (experienced) thought into it, because you aren't a cryptographic expert. You don't know what kind of patterns are common or not, or what is obvious to reverse or not.
Second, as a second-order attack, going after passwords-generated-from-URL isn't that hard.
To analyze the algorithm's strength, I actually need to know how you came up with the above algorithm, rather than the details of the algorithm itself.
For that algorithm - and the one I actually use - I just made up rules similar to those until I had enough characters.
Yep, "I'm creative, so nobody else will be creative in the same way" cryptographic defence.
This is why "security through obscurity" is not security. Because your creative rules are only strong because they are "obscure" (when they aren't actually that obscure -- and, more importantly, you have no reason to think they are obscure!)
Again, my hope is that the output just looks like a machine generated password, which doesn't follow any of the usual predictions about location of capital letters at the beginning, or numbers in place of vowels in dictionary words, or four-digit years appended to proper names, and so on.
A low enough bar allows even an ant to walk over it.
And yes, it isn't hard for a machine to see a letter-number combination and check the same pattern somewhere else. Or do some comparisons of your letter-number pattern to other parts of your password, or the layout of the keyboard, or the URL that the password is attached to.
About the only defence I see your mechanism providing is that of swimming faster than the guy next to you when trying to outrun a shark. Ie, the crackers having so many people with even weaker passwords, it isn't worth bothering to attack yours. This, however, is still weak.