12

I have a scenario where I have to remember a password / keyphrase, which I will not be able to recover if I forget it, for a long time (probably more than 10 years). The problem is because this password is part of a disaster recovery strategy I will hopefully not need it very often.

Are there any techniques or methods to choose a good password for this situation and to keep it in my mind?

Martin
  • 535
  • 3
  • 11
  • Diceware passphrases. – Natanael Dec 13 '15 at 16:13
  • 2
    Welcome to the edge at the end of the world... Not gonna lie to you, I would keep that password simple and probably base it on prior knowledge. What will greatly affect your odds at remembering it, though, is avoiding memory interference. Don't make that password similar to one you already have and modify elsewhere, or you won't remember the exact composition of that one when you need it. If you go for something complex, you can decide to train yourself by using it every other day/week (that's a considerable amount of effort though). – Steve Dodier-Lazaro Dec 13 '15 at 16:22
  • 2
    (also, before someone writes an authoritative answer I should point out that there's no research on long term password recall) – Steve Dodier-Lazaro Dec 13 '15 at 16:39
  • 1
    Tattoo on the inner thigh would work. – TTT Dec 14 '15 at 16:46
  • DR system not tested often? What kind of disastrous decision this is? – billc.cn Dec 14 '15 at 17:55

9 Answers9

18

Likely the best option in this kind of scenario is to record the password/passphrase in a physically secure location (e.g. bank vault, safe deposit box).

Relying on human memory to record this kind of information for 10+ years is an extremely bad idea. For example the person who knows the passphrase leaves the comapny/gets hit by a bus/forgets it.

Writing it down and storing it in (preferably 2+) secure location avoids this kind of issue.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
2

I use the following system:

Hash a string of these three parts

  1. A fixed, long and impossible to guess prefix (I diceware'd a 10-word phrase)
  2. The current date to the precision that you can easily recall/depending on the frequency you change it (e.g. use year only if changed once every few years in case you forget the month)
  3. An intuitive and succinct description of the purpose of the password (e.g. domain name of the website or a single word like "DR")

Use this pattern to generate all your passwords so you'll never forget the fixed prefix. Parts 2 and 3 prevent collision so if any password is revealed, you don't have to remember a new prefix (and then forget the old one by mistake).

billc.cn
  • 3,852
  • 1
  • 16
  • 24
  • I use this (currently without the second Parameter) for my everyday passwords. But i thought i should use something else for DR – Martin Dec 14 '15 at 18:22
  • @Martin Any particular threat that makes this unsuitable for DR passwords? Using a different system just for the sake of non-everyday system feels like security by obsecurity to me. – billc.cn Dec 14 '15 at 18:38
1

You could set the same passwort on another account which you use more frequently. But keep in mind that this might be a security issue.

Or choose something that is connected to the account or software or whatever. (Example for a google account: Password=$G00gleP4ssword!)

Another way is to remember a sentence and then use the first letter of each word. For example "My name is martin and its the year 2015" would be "Mnimaity2015"

Lexu
  • 936
  • 1
  • 7
  • 14
1

After reading some interresting ideas here I came up with something else and would like to get some feedback on this.

What if I remember the "pointer" to some public information and use this information (or parts of it) as the passwort.

Example: I remember the title of a book and use the first sentence as passwort. That way I have a short and easy to remember key that leads me to a long and thereby strong password.

Martin
  • 535
  • 3
  • 11
1

I'd say that the questions to ask yourself are "How many times am I going to need it?" and "How secure does it need to be?".

If it's infrequent and insecure, then something that you're going to remember. Focus on memorability over all else.

If it's infrequent and secure, then generate a suitably secure password, record it and store it physically (safe, safety deposit box, etc.).

If it's frequent and insecure then apply your typical policies.

If it's frequent and secure, then you'll be wanting a password manager to store secure passwords.

Jozef Woods
  • 1,247
  • 8
  • 7
1

Generate a good passphrase using Diceware. Memorize it. Think of the passphrase once every day (make it a routine, for example always recall the passphrase when you go to bed).

fakeember
  • 19
  • 3
1

Use a password manager, such as KeePass or LastPass, for all passwords related to the domain that includes your disaster recovery (if it's for work, use the PM for your work-related passwords.) Include the disaster recovery password in the database, and keep your password manager's database backed up. This means you're still responsible for practicing good security with the password manager - perhaps an isolated machine with flash drive and CD-ROM backups, etc. You'll use the Password Manager's password every day, and won't forget it.

You can certainly keep multiple databases for your PM. I wouldn't store my work passwords in the same database where I keep my personal passwords, for example; my work has a policy against that. I change my work db password every 90 days to comply with work policy about password changes, but I don't necessarily have to change all the passwords stored in it (subscriptions to work related web sites, API keys, etc.) This would be an ideal place to store a little used key.

John Deters
  • 33,650
  • 3
  • 57
  • 110
-1

Random character sequence is hard to crack, but also hard to remember. Words (or concatenation of words) are easy to remember, but also easy to crack with brute force methods, such as iterating dictionaries of words. An ideal thing is a mapping between intelligible words and (apparent) random sequence of characters.

So let us start from a phrase that is easy to remember, such as "I love pizza".

The strategy to convert common words into obfuscated stuff is to use the ASCII codes of characters. Consult ASCII table :

I -> 73 (it's capital I), whitespace -> 32, l -> 108, o -> 111 and so on

This convertor turns "I love pizza" into "073 032 108 111 118 101 032 112 105 122 122 097" . Of course, you can remove the white spaces between the codes, and also add an uppercase letter and a special character (some that you will surely remember), to make the password compliant to password policies.

The generated string - "073032108111118101032112105122122097" - looks pretty random. There is no way to guess that every group of 3 consecutive digits has a special meaning. Maybe the higher frequency of 0 and 1 could suggest they represent delimiters - or the fact that on every 3rd position, starting with first position, there is either a 0 or 1, but that's hard to notice. Just in case, you can multiply this with a key number, lets say, 2. The resulting number will no longer be an ascii representation of intelligible characters, unless you divide that with the key number that only you know.

The nice thing is that all you need to remember is the phrase "I love pizza", go to the website that makes the conversion, and that's it, you have your password.

A second strategy is to write this phrase in a text editor (take care with any extra whitespaces, tabs, new line characters, as they will affect the output), save it as a .txt file, and than compute the checksum of the file with a tool such as WinMD5.exe . The checksum will be your password. I must emphasize that the tool is consistent - I computed the checksum for 3 different files, but all containing the same text "I love pizza" (with no space after), and everytime I got the same checksum, which is 3341068d21d0b7b773518d08d21450b0. Again, you can add at the end a special character, maybe an uppercase letter, just to make your password compliant with any policies. And, again, you will not need to remember anything else than the phrase "I love pizza", and the tool will generate the password for you.

wile the coyote
  • 1
  • *"There is no way to guess" "The checksum will be your password."* It's usually assumed that an attacker knows how your password is generated. They just don't know the *output* of the process. There's no problem if I tell the world that my passwords are randomly generated out of this-or-that set of characters and such length, or that they are Diceware passphrases, or whichever, *since this doesn't give you much of an advantage* if the password is strong enough on its own. – user Jul 04 '19 at 08:14
  • 1
    However, if I were to tell an attacker "it's the ASCII decimal numeral representation of a natural language phrase", that reduces the search space *considerably* thus greatly reducing the security. MD5 hashing the same phrase has the same problem; in both cases, you are just representing the password seed in a different way. Changing the representation does not and cannot change the amount of randomness of a chunk of data. – user Jul 04 '19 at 08:14
-2

If you have some type of programming experience - you could make your own encrypted password manager and put all your passwords there. You could move the password manager to a MicroSD card incase you are afraid your system might fail and even encrypt the MicroSD card for some extra privacy.

XtraBuzz
  • 1
  • 5
    Why should he make his own password manager and not use an already existing? – Beat Dec 13 '15 at 17:23
  • 2
    Worst answer. "Some type of programming experience" does not qualify someone to write a secure password manager. – Samuel Dec 14 '15 at 09:21
  • I am susprised that nobody recomended a password manager. Is this too risky? Wouldn't the physical secure location lead to a post-it in the drawer? Most people won't have a bank vault or safe box. Specially at work. – borjab Dec 14 '15 at 12:45
  • 1
    Password manager, yes. Roll your own, no. Physical security is good for high-importance, low-use information (root/administrator account, management encryption keys, etc.), when you get to that point, the financial outlay is negligible for the security, and the possessor of the physical security mechanism (safe, deposit key, etc.) is assumed to be the authorised person. – Jozef Woods Dec 14 '15 at 13:54