2

I came across this article discussion how to make a password secure by adding your own "encryption" scheme to a selected word and create you password.

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?

Gavin Youker
  • 1,270
  • 1
  • 11
  • 23
  • The answer is about the risk assessment you make about each place you use your scheme. When is it appropriate to simply use "password" as your password? – schroeder Dec 06 '16 at 22:49
  • 1
    This is similar to http://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. – Ajedi32 Dec 08 '16 at 16:44

3 Answers3

2

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

Password managers, when combined with long, randomly-generated passwords, operate on an approach I like to call "put all your eggs in one basket, and guard that basket really really well". The length and randomness of the passwords protect against brute force and dictionary attacks, and the randomness also prevents password-sharing attacks where one site stores your password insecurely. The primary attack vector, of course, is an attacker gaining access to your password manager database, at which point they gain access to every account of yours.

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.

Xiong Chiamiov
  • 9,384
  • 2
  • 34
  • 76
1

Short answer: Bad advice.

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).

Marcus Müller
  • 5,843
  • 2
  • 16
  • 27
  • 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. – John Wu Dec 06 '16 at 23:04
  • 1
    @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. – Marcus Müller Dec 06 '16 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. – John Wu Dec 06 '16 at 23:15
  • 1
    yes, indeed, but it's by far not as enormous as the whole space of possible n-character passwords – Marcus Müller Dec 06 '16 at 23:56
  • Think we are thinking about this differently. Consider a 4-digit PIN. Your transformation is to add a constant to it, some value between 0 and 9999 inclusive. That is one transformation with 10,000 possibilities, already exceeding the entropy of the password. I could also add, multiply, XOR, whatever. – John Wu Dec 07 '16 at 03:07
  • 1
    @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. – Marcus Müller Dec 07 '16 at 10:51
0

Short answer

Depends on your "cipher."

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.

John Wu
  • 9,101
  • 1
  • 28
  • 39