0

Introduction

For a long time I have struggled with (the idea of) password management. Remembering unique strong passwords is impossible when one has more than a handful, which only leaves the option of using a password management system of some sort. The conventional backed-up randomly generated passwords never appealed to me, as it gets increasingly difficult to update your database of passwords with every back-up copy—and I would demand a lot of them (I refuse to ever lose my passwords).

Naturally I became interested in deterministic password-generation algorithms and I carelessly and stubbornly searched for an answer, to no avail. Time passed, and as I—on an unrelated journey—got familiar with the crypto-currency technology, the final puzzle started to fall into place. I formulated a password generator that doesn't need any back-ups, but it has not been scrutinized by anyone, let alone security experts. Hence, this is my plea and question to you: Is there a flaw or are we ready to revolutionize password management?

I will present the idea in two parts. Firstly, an explanation of the crucial obfuscation process—the final piece of the puzzle— that was inspired by Bitcoin's standard to safely store keys.


Part one: the obfuscation process

This wordlist of 2048 words is widely used in the crypto-currency space. It is used by taking a hash, appending to it a checksum sliced to the length of [entropy/32] in order to make it divisible by 11, and dividing it into segments of 11 bits—each segment corresponding to one of the words in the list (00000000000 would be the first word—"abandon", and 11111111111 would be the last word—"zoo"). Thus the hash is converted into a string of human-readable words.

Here is an infographic from Mastering Bitcoin that illustrates this:

enter image description here

Example:

Password:

"CorrectHorseBatteryStaple"

SHA-256 sum:

7abdae32d3c9fd31959fd66c8c48de11bdff24b1dad2542f46faa0ebc50329fe

(01111010 10111101 10101110 00110010 11010011 11001001 11111101 
00110001 10010101 10011111 11010110 01101100 10001100 01001000 
11011110 00010001 10111101 11111111 00100100 10110001 11011010 
11010010 01010100 00101111 01000110 11111010 10100000 11101011 
11000101 00000011 00101001 11111110)

SHA-256 sum with check:

7abdae32d3c9fd31959fd66c8c48de11bdff24b1dad2542f46faa0ebc50329fe5b

(01111010 10111101 10101110 00110010 11010011 11001001 11111101 
00110001 10010101 10011111 11010110 01101100 10001100 01001000 
11011110 00010001 10111101 11111111 00100100 10110001 11011010 
11010010 01010100 00101111 01000110 11111010 10100000 11101011 
11000101 00000011 00101001 11111110 01011011)

SHA-256 sum with check split into segments of 11 bits:

  • 01111010101 (981 - "kind")
  • 11101101011 (1899 - "unhappy")
  • 10001100101 (1125 - "milk")
  • 10100111100 (1340 - "polar")
  • 10011111110 (1278 - "panic")
  • 10011000110 (1222 - "obvious")
  • 01010110011 (691 - "film")
  • 11111010110 (2006 - "wide")
  • 01101100100 (868 - "hockey")
  • 01100010010 (786 - "giraffe")
  • 00110111100 (444 - "danger")
  • 00100011011 (283 - "cash")
  • 11011111111 (1791 - "thank")
  • 10010010010 (1170 - "mutual")
  • 11000111011 (1595 - "shrug")
  • 01011010010 (722 - "focus")
  • 01010100001 (673 - "favorite")
  • 01111010001 (977 - "key")
  • 10111110101 (1525 - "salon")
  • 01000001110 (526 - "double")
  • 10111100010 (1506 - "rotate")
  • 10000001100 (1036 - "lift")
  • 10100111111 (1343 - "pond")
  • 11001011011 (1627 - "slender")

We don't need all 24 words. Taking the first 7 words we get 2048^7 > 10^23 possible passwords. That should be enough entropy.

Obfuscated password:

"KindUnhappyMilkPolarPanicObviousFilm"

This allows us to generate human-readable hashes of our passwords, which means that our passwords can be extremely similar to each other, because we will keep them secret and use their obfuscated forms instead.


Part two: the complete system

The idea is to have one strong master password for the rest of your life that works as a salt. A new password is generated by appending a name (presumably of the website) together with an integer (for multiple passwords on the same website) to the master password before it is obfuscated to create the password.

Let's assume our master password is "CorrectHorseBatteryStaple".

I wish to create a new account on StackExchange and decide to generate a password for it:

  1. The password manager asks for a name and number (default: 1) for the password. I type "StackExchange" and change the number to 2, as this would be my second StackExchange account.

  2. The password manager turns the name into lower case, and appends it and the number to the master password: "CorrectHorseBatteryStaplestackexchange2"

  3. The password manager obfuscates the string and presents the obfuscated password for my new StackExchange account to me: "ParentTinyGiftCenturyCurveBlessInput"

The password manager can save these passwords, but it is unnecessary. Whenever I want to log in to my second StackExchange account I can simply write "stackexchange" and "2" in the two fields in order to be presented with my password.


There are a few obstacles that need to be tackled. Many websites have silly restrictions on passwords such as a maximum password length of 20 and requiring non-alphanumberic characters. These problems could be bypassed by simply ending every password with an asterisk and allowing for 4-word passwords in addition to the standard 7-word password. However, I am unsure about whether it is the correct approach to include these hacks, as this should be a widely adopted standard rather than merely used by a small minority of enthusiasts.

Adoption is important to reduce fingerprintability. I am currently using this technique for my passwords, but since I am the only person on the planet who uses it, I cannot use it when I want to be anonymous. That is a major problem, but one that eventually goes away if this turns out to be as widely adopted as I think it deserves to be.

Compared to conventional password managers, this is—as I can see—more secure and incredibly more convenient (which plays a major role in adoption).


Update: I am not exactly sure why this is off-topic, but in any case I realize that my idea is infeasible after reading the comments and reflecting over them. This question may now be closed.

closed as off-topic by forest, Rory Alsop Jan 9 at 9:00

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Rory Alsop
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    As a first step think like an attacker. It is up to the inventor of a new method to do the research, there is no reason to believe knowable crypto experts will take their time to review such a scheme without serious literature review by the author. Obfuscated is insufficient. Obligatory: "Schneier's Law": "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." – zaph Jan 9 at 1:04
  • You haven't mentioned current best practices such as Argon2 which require substantial time and/or memory. You must show that your menthod is at lease as secure. Review and compare to NIST Digital Identity Guidelines (unfortunately not currently available). Show that this scheme to not vulnerable to rainbow table attacks, etc. – zaph Jan 9 at 1:20
  • 3
    Before coming up with a solution to an existing problem, you need to first consider how existing approaches fall short. Otherwise, you end up inventing solutions to problems that don't exist. That seems to be the case here. – Stephen Touset Jan 9 at 1:56
  • 2
    Voted to close as primarily opinion-based/off-topic because security.SE should not be used to audit home-grown algorithms. Even for ones that has gained traction they should go to crypto.stackexchange.com, not here. – Voile Jan 9 at 3:07
  • ...or are we ready to revolutionize password management? Probably, the next revolution is finally going to remove passwords, in preference for some sort of distributed id. Something like, say, an "internet driver's license". Remember that passwords are absolutely not a goal - they're a necessary part of a solution. The actual goal is proving your identity to a requestor. – Clockwork-Muse Jan 9 at 5:44
7

This is a lot of trouble to go to for little additional benefit - compared with simply using a strong, random master passphrase, coupled with 2FA, to protect a password vault (within which each password can be completely random, and unrelated to both your master password and to all of your other passwords).

If the attacker somehow discovers your scheme, and if they learn your master password via any means at all, they can determine your password on all websites. And unlike using a master password for a password vault, they don't have to compromise your computer or your vault provider, or to even log into your vault provider, to use them.

  • CRYPTO-GRAM,October 15, 2017, by Bruce Schneier: ... use password managers ... – zaph Jan 9 at 2:25
  • Are you saying that one should not back up their password vault or that updating back-ups of one's password vault requires little trouble? I don't see how either of those statements is true. I did say that I find password management incredibly difficult, so it's not "little additional benefit" as I see it. What am I missing? – Gendarme Jan 9 at 8:11
  • @Gendarme 1: Security it a PITA, get used to it. 2: Decide on a per-site basis the security and the level you need. Examples are a bank account vs a site where you don't care. 3: Backup can be easy with services such as Backblaze, iCloud, Time Machine, etc. I'm the paranoid type so I have on-site backups that run every hour and others that run every day but that is overkill. 4. For passwords periodically print them out and put that list in a secure (not fireproof) safe, possibly at your bank. Cheap flash drives are also good but put then in individual large labeled envelopes to prevent loss. – zaph Jan 9 at 13:06
  • @Gendarme, all I meant is that your proposed method is significantly less secure than what I outlined in my first paragraph, for the reasons outlined in the second paragraph. The more deterministic a scheme is, once your methodology is known, it can be more easily compromised - which is less compliant with Kerkhoff's principle. I see that you're trying to trade a little security for more usability, but you're sacrificing more security than may be apparent. – Royce Williams Jan 9 at 23:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.