# When should a password cipher be used and when should a normal password be used? [duplicate]

For example, if my cipher was to add four zeros, switch every word in the alphabet with it's reverse letter, and attach with my favorite number.

Examples

• Google = `0000tlltov7`
• Stack = `0000hzxp7`
• etc...

The idea here is to simply remember the cipher, not the password. The clear text comes from the name of the website/company(Apple, Microsoft, Google)... but is this a better way than creating passwords?

Sure, every password is unique and extremely difficult to brute-force, but the the scheme exposes it all. If an attacker were to find out my scheme, they would know all of my passwords. When is it better to use password ciphers? When is it better to use normal passwords?

• This is similar to security.stackexchange.com/q/94106/29865, except you're using a weak hashing algorithm that you store in your head instead of a strong hashing algorthm stored on your PC. Commented Dec 8, 2016 at 16:44

## The rule

If the cipher results in a search space that is as large as the search space required for brute force, your scheme is 100% effective.

## Example

To explain this, let's use a trivial example. Assume there is a very poor web site that requires a four-digit alphabetical password.

The brute force search space is 26^4 = 456976.

Meanwhile, there are only about 4000 four-letter words, so the default dictionary attack search space is only 4000. Very bad.

Now let's say you use a very simple transformation: take each letter and add one, so A become B, B becomes C, etc. In order to search the dictionary and this simple transformation, the attacker must now search a namespace containing 8,000 entries. This is a bit better.

Now, the attacker won't know you are adding one. He may suspect it. But he may also need to check +2, -1, and -2. That's four transformations totalling 16,000 sequences. Still poor, but better than 4,000.

Now, there are probably a lot of possible transformations you could come up with that you could do in your head. Shift your hands one key to the right and touch type. One key left. Type the word backwards. Swap vowels and consonants. Etc, etc. If there are 100 transformations, now the attacker has to search 400,000 possible sequences. Hey this is looking pretty good.

At some point the attacker is going to give up looking for novel transformations because it will result in a search space greater than that required for brute force, 456976. The moment that happens, your scheme is 100% effective.

## If you really want to make it secure

If you really want to make it secure, introduce a secret. For example, memorize a poem, then map each letter of alphabet to a line in that poem, and substitute the first letter of the line for each letter. If the attacker doesn't know the poem, he will have a helluva time writing a program to guess it. Unless he reads the same literature as you he may never figure it out. Now perhaps a clever hacker out there will introduce a poem database into his search algorithm, but in the end it is going to end up being more computationally expensive than a plain brute force attack.

## Conclusion

If you're made the dictionary attack more expensive than a brute force attack, the hacker will use a brute force attack. That is best case scenario, since there is no way for an end user to mitigate brute force through choice of password.

It seems unlikely this hasn't been asked here before, but I couldn't find a good duplicate.

If you can remember all of these long, randomly-generated passwords, then there is no database to breach, and you're better off. However, most people can't do this.

As an alternative, you can use an algorithm to reproducibly generate a password on-demand for a site (a number of options are described in What is your way to create good passwords that can actually be remembered?). These retain the benefit of not having a breachable database. The question, then, is to whether or not the benefit of avoiding the database of passwords outweighs the downsides of moving from randomly generated passwords to a reproducible scheme.

If the scheme is obvious upon looking at a plaintext (e.g. `siteName + accountName`), then one breach at an insecure site opens up your entire set of accounts to any attacker who happens to look at your password. This is obviously pretty awful from a security perspective. Most schemes aren't that obvious, but you're betting on the attacker to not be able to reverse-engineer it - whether that's a good bet or not is up for debate, and depends on your specific scheme as well. It's worth noting that the chances of successful reverse engineering go drastically up as an attacker gains access to plaintext passwords from multiple sites.

Another issue with reproducible password schemes is that they don't provide an easy way to change your password for a site - they are reproducible, and to generate a new password, you would need to integrate an additional piece of information (some sort of "round"), which you then need to either store or memorize.

Both password manager use and reproducible password schemes are security downgrades from the ideal password memorization option. They are also both much better than what most people do, which is to use the same insecure password across many accounts. Which one is "better" depends a lot on the specifics of your password manager and the scheme you're comparing it against, and which attacks you're worried about.

Don't do that. A single password, recovered from eg. a password database hack that publicized the list of passwords, would immediately break your security. It's thoroughly despisable to recommend something like this.

And even without that, an attacker would probably do both – a simple dictionary attack based on common passwords, and a slightly more advanced dictionary attack based on modifications of the user name, the site name, the birthday of the user etc.

Would it be better to make strong passwords for every different website or to use a universal cipher, maybe a mixture of both somehow?

Obviously, yes. A random password doesn't get any securer by getting encrypted, so just use a random source of characters as password generator. Under linux, `dd if=/dev/urandom bs=1 count=256|md5sum` is a nice password generator (urandom gives the exactlysame things as /dev/random).

• Not sure you understood the question. A single hack would not break his security, and a modified dictionary attack doesn't apply here, as a dictionary is a list of symbol sequences, not character transformations. Commented Dec 6, 2016 at 23:04
• @JohnWu In my vocabulary, a dictionary attack combines a wordlist with a set of transformations of the same and tries those. So yes, what I describe is a dictionary attack. Commented Dec 6, 2016 at 23:10
• In a dictionary attack, the word list is predetermined and the transformations are predetermined. In order to crack the sort of the thing the OP is proposing, you'd need the software to come up with its own transformations and explore them until it finds the right one. That is an enormous problem space. Commented Dec 6, 2016 at 23:15
• yes, indeed, but it's by far not as enormous as the whole space of possible n-character passwords Commented Dec 6, 2016 at 23:56
• @JohnWu but that's exactly not what we're discussing. We're discussing website passwords, where the space possible passwords is not 10^4 , but more like 127^16, and a (naming this conciliatory) "List of transformations" attack is far far far more feasible than to brute force the password. Commented Dec 7, 2016 at 10:51