2

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.

Is this method secure? Are there better alternatives?

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
Thomas
  • 3,841
  • 4
  • 22
  • 26
  • I certainly hope that's not *actually* a hash of your Facebook password. Just sanity-checking. – Iszi Jun 24 '13 at 22:01
  • Nope it is not :) I realize that it is easily found using the reverse lookup. – Thomas Jun 24 '13 at 22:01
  • 3
    If it's "easily found using the reverse lookup" then you're Doing It Wrong™. – Iszi Jun 24 '13 at 22:06
  • @Iszi: It was just an example to illustrate what I was talking about. I guess one could run ones hashed passwords through reverse lookup and see if they are easily found. – Thomas Jun 24 '13 at 22:07
  • You can have a hashed password that's not readily found through a certain reverse lookup, and still be Doing It Wrong™ - that just means your password isn't in that particular database yet. If *any* password is findable in a database, using your hash function, then you *really* need to re-think your implementation - or just stop trying to make your own altogether. – Iszi Jun 24 '13 at 22:09
  • @Iszi: Would you write an answer? (I would like to hear how safe this method is. It sounds like you are saying that it is not safe at all). – Thomas Jun 24 '13 at 22:11
  • That's not what I'm saying at all, in the context of my comments here. (Generally, we'll see what the answers say.) What I'm saying is that there are ways of hashing passwords that are secure, and there are those that aren't. A proper implementation would require a dedicated brute-force attack on each password - you shouldn't be able to find *any* of the hashes (even for "god", "letmein", "password", etc.) in *any* database, because a proper hashing implementation (which includes unique salts) will result in an output that's *very unlikely* to match *any other pre-existing hash in the world*. – Iszi Jun 24 '13 at 22:15
  • 1
    I'd suggest lastpass.... – Griffin Nowak Jun 25 '13 at 01:08

3 Answers3

14

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

  1. HashPass does not use any encryption. Otherwise, it may as well just be another layer on top of something like KeePass/TrueCrypt.
  2. 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.
  3. 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.
  4. 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.

Iszi
  • 26,997
  • 18
  • 98
  • 163
  • 1
    +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 08:04
  • Also you're missing a reference to [AviD's Tenet of Usability](http://security.stackexchange.com/a/6116/33) :D – AviD Jun 25 '13 at 08:05
  • 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. – Iszi Jun 25 '13 at 15:38
  • tl;dr, but +1 for the first paragraph ;) – tylerl Jun 28 '13 at 01:53
4

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.

petiepooo
  • 117
  • 5
  • To clarify, when I talk about a written list of sites and hashes/hints, I mean a paper list. The proverbial post-it under the keyboard. – petiepooo Jun 24 '13 at 23:22
  • Thanks for this answer. I hadn't thought of your first point. Simply storing the first couple of bytes seem to work. – Thomas Jun 25 '13 at 12:25
1

Short answer: Your method is not secure.

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.

Moustache
  • 636
  • 5
  • 9
  • 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". – Moustache Jun 24 '13 at 23:26