I remember all the passwords (and variations of passwords) that I use for various sites online. The problem is not that I forget a password, but that I forget which password goes with which site. And one usually only gets a few tries logging in somewhere.

So my idea is to create a file with the various places. For each place, I will then have the password to that place hashed. So it might say

facebook.com: 9a618248b64db62d15b300a07b00580b

That way, if I forget a password to facebook, I can go through the list of possible passwords and generate the hash for each one. The one that has a hash matching the one saved is the password.

3 Answers
3

"Is [x] secure?" or "Is [x] more secure than [y]?" is always a tricky question to answer. In the end, you have to boil each option down to the strengths and weaknesses of its components and then make the decision based on your own needs to balance security and usability.

Here, your method of protecting passwords is best compared to existing tools like KeePass and TrueCrypt. I'd like to give you my comparison of these options in terms of Confidentiality, Integrity, and Availability (three core tenets of security) as well as Usability. For our purposes KeePass and TrueCrypt are on roughly equal grounds, so I'll just lump those together. We'll call your method HashPass.

First, a few assumptions must be made in order to perform an objective analysis.

HashPass does not use any encryption. Otherwise, it may as well just be another layer on top of something like KeePass/TrueCrypt.

Users are using the same password on multiple systems, but perhaps not all. Whether you personally do this or not will affect the level of security offered by HashPass. However, to answer this question for the general case, one must assume a "normal" end-user and they very often re-use passwords.

HashPass uses a unique salt for each entry. This is general good practice for hashing passwords, to prevent a single pre-computed table from being able to break the entire database in one swing.

HashPass is using a tried-and-true hashing implementation based on a strong algorithm. Otherwise, we almost might as well not bother hashing.

Confidentiality

HashPass

Pros

Each password must be individually attacked.

Cons

Weak passwords may be compromised faster. These passwords may be weak due to user choice, or due to restrictions of the systems on which they are used - the latter being beyond the control of HashPass or the user.

Knowledge of one site's password greatly simplifies attacks on entries for other sites where that password is reused. This may be gained by any number of means, many of which do not require a compromise of the local system.

KeePass/TrueCrypt

Pros

The database password can be as long and complex as the user likes - potentially well beyond the limitations of some or all of the systems represented in the database.

The database may additionally be protected by the use of key files or other authentication mechanisms which go well above and beyond the protection of a simple password.

The database key(s) cannot be attacked or stolen without first compromising the local system, unless the database is protected by a password that is also in use on a remote system and it is not additionally protected by a key file(s) or other authentication mechanism. (In short, protection of the database key(s) is entirely within the control of the user.)

Cons

Compromise of the database key will result in simultaneous compromise of all passwords in the database.

Integrity

HashPass

Pros

I can't think of any, in comparison to KeePass/TrueCrypt.

Cons

Protection of the database's Integrity is entirely dependent upon the host system. Individual passwords may be deleted or overwritten without deleting or modifying the rest of the database and without any foreknowledge of any of its passwords.

KeePass/TrueCrypt

Pros

The database's Integrity is protected by the same key which protects its Confidentiality. Without that key, an attacker cannot modify or delete individual keys - they can only delete the entire database.

Cons

I can't think of any, in comparison to HashPass.

Availability

HashPass

Pros

You can forget one or more passwords, but still have the ability to verify other passwords in the database.

Cons

You need to remember every password in the database, to verify every password in the database. If you forget a password, there's no way to get it from the database.

KeePass/TrueCrypt

Pros

You only need access to one key (though it may contain multiple components, at your option) to gain access to all passwords in the database.

You never need to remember any of the passwords in the database.

Cons

If you forget that one password, or lose/forget any of the other key components, you cannot access any of the passwords in the database.

Usability

For the Usability section, I'm going to compare a few "forgotten password scenarios" and also throw in "No Password Management" as an option as a baseline.

No Password Management

If you've forgotten which password you used, but can guess it in the first few tries...

You will brute-force your passwords on the target system until you eventually gain access.

If you've forgotten which password you used, and it takes you numerous attempts to guess the correct one...

You may trigger an account lockout and/or imposed password reset/recovery. A password reset may not permit reuse of previous passwords. Account lockouts and/or imposed password reset/recovery is becoming more the norm, but many systems still do not implement this. Prohibitions on password reuse is still relatively rare outside of high-security systems, but are becoming more common.

If the system does not use account lockouts or imposed password reset/recovery, you will eventually gain access.

If you've forgotten the password entirely...

If not automatically triggered, you will have to initiate a password recovery/reset process.

HashPass

If you've forgotten which password you used, but can guess it in the first few tries...

You will brute-force the passwords in HashPass until you guess the correct one, then will have to re-enter the password on the target system.

If you've forgotten which password you used, and it takes you numerous attempts to guess the correct one...

You will brute-force the passwords in HashPass until you guess the correct one without risk of triggering an account lockout or imposed password reset/recovery.

If you've forgotten the password entirely...

You will need to initiate a password recovery/reset process and update the database entry.

KeePass/TrueCrypt

If you've forgotten which password you used or forgotten the password entirely...

You will authenticate to the KeePass or TrueCrypt database and immediately have access to the correct password.

KeePass can even be configured to enter the password for you automatically.

If you've forgotten which password you used or forgotten the password entirely, and you cannot access the KeePass/TrueCrypt database (forgot KeePass/TrueCrypt password, or forgot/lost key files or other KeePass/TrueCrypt authenticators)...

You will need to initiate a password recovery/reset process and rebuild the entire password database.

In terms of usability, I believe KeePass/TrueCrypt clearly wins outright while HashPass is only a little bit better than no password management at all. In my personal experience, I've rarely - if ever - triggered an account lockout or imposed password reset/recovery by brute-forcing my own account. Usually I'll give up on brute-forcing it (which I'd still need to do with HashPass) before I hit a threshold anyway. It's also much easier to keep the one password (and/or other authenticators) in mind than it is to remember all the passwords in the database - which you effectively still need to do with HashPass.

For overall security, in "CIA" terms, both password management mechanisms have some areas where they have good strengths, as well as some pretty bad weaknesses.

How does everything balance out? I personally would prefer KeePass/TrueCrypt for its great usability benefits, the fact that its key strength is not dependent upon outside restrictions, and the fact that its key is not inherently obtainable from outside systems. Of course, the end decision is up to you.

+1, but I think you are conflating the "integrity" and "availability" - deleting passwords harms availability, not integrity. A challenge to integrity would be if I could change the password, not remove it.
–
AviD♦Jun 25 '13 at 8:04

Thanks for taking the time to write up this answer.
–
ThomasJun 25 '13 at 12:15

1

@AviD Arguably, deletion of a single password could fit into either. If you look at the database as a whole, it's a hit to Integrity. If you consider individual passwords only, it's Availability. I just didn't feel like listing it twice.
–
IsziJun 25 '13 at 15:38

Longer answer: Your implementation is as secure as your password is. By secure I mean how did you choose your password? What is the complexity of your password? Is it a truly random password or you are using words or/and keyboard patterns? You can have a look at this answer about the XKCD comic for more information about how to create a secure password.

Hashes are subject to bruteforce attacks (I don't mind how good youk think your password is). The choice of your algorithm is critical. You should also salt your password if you don't want your hash to be exposed to rainbow table attacks. There are few different problems in your method which you identified yourself already.

If you want a secure way to store multiple passwords you should use a password management software like keepass.

A good point from @petiepooo, if you need to write your password there is nothing wrong with that but don't keep the written piece on your computer. Keep it in your wallet or somewhere "safe".
–
MoustacheJun 24 '13 at 23:26

It is marginally better than storing your passwords in plaintext. But...

1) Since you're just matching your memorized passwords' hash to the list, you should truncate the hash to the first few digits. It's unlikely you'd get a collision in the first 7 chars or so with the number of passwords the average human can memorize, and gives ambiguity in searches to reverse the hash. Eg. compare a google search of the full hash above with just the first 7-8 characters.

2) You could also use a personal shorthand to describe your password. For example, if your passwords all have a common substring, you could use "CPP" or something similar, and append the site-specific portion after it. For example, if "supersecret" is the common part, and your facebook password was "supersecret123" you could write that in your file as "facebook: CPP123". That way, if someone got the file, they wouldn't be able to bruteforce the hashes, and it still relies on personal knowledge of what "CPP" means. Those hints could ease the job for an experienced password reverser, though.

3) You could also just encrypt your hint file, and decrypt it to screen/terminal only when your memory needs refreshing. In fact, that's a problem that's already been solved by a myriad of password lockers (eg. KeePass, Password Safe, etc.)

Your main computer is your castle. Once it's compromised, all bets are off, as the bad actor has access to all your files and can log your keystrokes to capture any passwords they like. So any password keeper or hint file should assume it will be stolen and minimize the damage when that occurs. For that reason, I prefer memorized passwords rather than relying on lockers for all logins, since a bad actor on your machine can watch you type the locker password, download the locker, and have every last credential. If you don't open the locker, then they only have creds for the sites you accessed while they were watching, which is bad enough.

I also don't think a written list of sites and hashes/hints is such a bad thing. I'd recommend not writing down the full password, of course, but at least then someone with remote access to your computer doesn't have everything they need. (That's assuming you don't have a webcam trained on it...)

Ultimately, I'd recommend you use a password locker. You don't have to put the actual password in it if you'd rather just put the hash or a hint in, but then at least your list of sites and hashes/hints/passwords are encrypted. And many people keep the file itself in DropBox or a similar service for when they need access to it from multiple machines.