password generating algorithm

Question

I read the question about the relevancy of the xkcd password creation algorithm.

Would it be more secure if you used a string of common words with a function that only you knew that would rearrange the characters of said common words?

Define a string of common words and a function f that rearranges the characters in the string in a pattern. Then let your password = f(string).

Using the xkcd password as the starting string: correcthorsebatterystaple.

f = rewrite correcthorsebatterystaple in a seemingly random but logical way.

So f(correcthorsebatterystaple) could become something like

csbthaapolteotrerrryseect

Would this have a greater level of security?

What if you allowed f to be any kind of transformation including transformations that added new information?

Answer 1

The short answer is No.

This is a classic example of Security through obscurity which while it may work sometimes is considered a bad idea because it never works out in the long run.

As in my answer to the other question it comes down to threat modeling. Consider the following two scenarios.

1) Attackers have downloaded a database of usernames and passwords with all the passwords stored as SHA1 hashes. They use rainbow tables or a dictionary of common passwords and try to break the weak passwords.

Is your system more secure? Yes, csbthaapolteotrerrryseect is unlikely to be in a password dictionary.

2) Attackers have downloaded a database of usernames and passwords with all the passwords stored as SHA1 hashes. They are targeting you and know your function, or maybe your function becomes wildly popular (like the xkcd one has) so the attackers run your function over their dictionary.

Is your system still more secure? No people will be looking for csbthaapolteotrerrryseect and similar passwords.

Kerckhoffs's principle is often used in cryptography and states that

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

This is a great asumption and it is used in the xkcd comic. Even if you know everything about how I generate passwords (including the list of words I use) there are still 2^44 possible passwords. Plus the huge advantage of the xkcd style is that it's easy to remember and type.

Answer 2

a function that only you knew

Well, such a beast does not really exist. Even if you can come up with some "mixing" procedure that lives in your brain only, it is quite hard to quantify how much that procedure is unknown to the attacker. If the said function exists as a script or executable file somewhere, or as a textual description on some blog post or policy document for users, then it is inordinately optimistic to believe that the attacker does not know it.

A big part of password security, even of security in general, is to know what kind of "security" you actually achieve. This means measures, metrics... You need that information because that's the only way to know whether your security controls are worth the effort. For instance, a password implies costs, in particular the time spent by the user to actually type that password. In a business context, costs translate to money; but even for private individuals, costs exist (e.g. as time spent, or as accumulated exasperation at dumb software). Your "private function" will have to be run in your head regularly. Will the gain in security be sufficient to offset the extra effort ? To answer that question, you must know that "gain in security"... and with a "private function", that's nigh impossible.

The whole point of entropy calculations is to come up with a good, mathematical, reliable measure of security. The only sane way to compute entropies is to assume that the attacker knows everything whose confidentiality cannot be quantified. Basically, we cannot reasonably measure how much a private function is private; for a randomly selected word in a specific list, we know how much it is unknown to the attacker: the attacker knows the list, not the randomly selected index.

---

There is a widespread tradition of generating password by accumulating semi-magical operations which are assumed to "look secure". For instance, people will add some punctuation signs because they believe that a '$' or a ';' has some "inherent security" which is higher than that of an 'A' or a 'k'. This relates to a notion of security being some kind of commodity that you just pile up. This is, of course, a very poor way of thinking about security. This would be like ensuring the security of a Web server against online attacks by keeping an armed guard in the server room -- and then proceeding with "doubling the security" by adding another guard. This would be ridiculous, but when it comes to passwords most people are ridiculous.

So, be smart: don't rely on rituals whose benefits cannot be measured or even estimated numerically.

Answer 3

From a cryptographic standpoint people will tell you it's wrong to do so. It's certainly not "more" or "equally" secure, but I think it's secure enough.

From a practical standpoint, for your personal passwords, it's not always feasable to remember passwords like A4q!qtrqFET4KmpVW.?T5"r'&141EFQFSq. If you force people to do so anyway you will end up with sticky notes or papers attached to a screen. One can argue that keeping passwords on a note in your wallet can actually also be considered secure (just don't write down usernames and what you use them for).

It's important to keep your system secret and to not over-use it, maybe only for those passwords you frequently use. If you can you should use a password manager. You should not use it for technical accounts.

Answer 4

Others have addressed the fact that you are violating Kerckhoffs' Principle. I'd like to suggest a way to recast your proposal that doesn't do so.

Making your function be part of the key

If we treat your "function that only you know" as part of the "key" then it is not a violation of Kerckhoffs' Principle. That is, we take your "key" to have two parts. The input passphrase, p, and the secret function, f.

Is your function deducible from its output?

Are you going to memorize both p and f? Probably. Are you going to use a unique p and f for each service that you uses? Probably not.

That is, I expect that you would be tempted to only change p for different cases while reusing the same f. This can be made safe, but what you describe with your example is not. That is because if an attacker gets a hold of a couple of your derived passwords, say f("correcthorse") and f("batterystaple"), they will be able to figure out what f is.

Fix by making your function a pseudo-random function

So if you want to do this, you will need an f that isn't not deducible from the attacker has n of your derived password, f(p1) ... f(pn). There are cryptographic functions that will do this for you. HMAC is what comes immediately to mind.

Let f(p) = HMAC("some constant secret only you know", p)

This way, an attacker who got old of f(p) would have a difficult time trying to discover the constant secret, particularly if they didn't know p.

Encoding issues

Note that the output of f(p) is not going to be ASCII text. So you would need to transform it into something usable as a password where you need it. It is hard to do this generally. For example if you used base64 encoding, you would need to make sure that the place you are using the generated password will accept all of the symbols that can appear in base64. Likewise, if you use a hex representation, you may not get all of the "symbols" that some services may require for a password.

It's these encoding issues why this system won't work as a general scheme. It can be used and then manually tinkered with on a case-by-case basis, but that means that you can only use it for a couple of cases.