What is the best, most secure, easiest way to:

  • store unique, strong passwords for every service which requires authentication
  • make the system resistant (total loss of security is avoided, breaches are contained) to multiple potential points of failure including:
    1. loss of the password list
    2. loss of any master password protecting the password list - loss of a password
    3. loss of two or more passwords which can be linked to the same person
    4. keyloggers

closed as not constructive by Rory Alsop Nov 3 '11 at 8:38

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I don't understand the requirements. Are you looking for a server-side solution? A client-side solution? When you talk about keyloggers, are you talking about keyloggers on the user's platform (client-side) or on the server? When you talk about loss of passwords or password lists, what passwords are you referring to? What is your threat model? Are you trying to defend against client-side malware, or server compromise? – D.W. Nov 3 '11 at 5:07
  • Question appears abandoned, all the answers are relevant to this original version, so I have rolled back and closed it. – Rory Alsop Nov 3 '11 at 8:39
  • @D.W. client-side. I'm looking for a practical storage solution for users to manage high entropy passwords which are unique to each site they use and is resistant to failure (i.e. most software password managers completely fail if the master password is compromised). – user5614 Nov 4 '11 at 3:11
  • @RoryAlsop Why do you say it's abandoned? I can only edit the question to make it fit the Q&A format. I can't edit previous answers. – user5614 Nov 4 '11 at 3:12
  • 1
    @myq, while I'm not persuaded about closing the question, I will concede that at this point the thread is a bit of a mess. The original question asked one thing, and got a bunch of answers. Then the question was completely rewritten, and now the answers are unintelligible. I think the new question is probably a better attempt at framing something suitable for this site, but it may make more sense to ask it as a separate question, so it's not polluted by left-over answers to the prior question. – D.W. Nov 4 '11 at 3:16

@bstpierre I didn't realise that the validity of a security system involves length of explanation. This is a proposal to address a real world problem as simply and robustly as possible.

The length of explanation for a system to be directly implemented by humans very much does matter. Most people that I know are hardly willing to choose a single good password, never mind manipulating strings the way this proposal does.

But let's be generous and assume that a user can handle the complexity. The scheme still has several problems that keep it from being usable.

First, it generates passwords like -----A1A8+QdjkD(*. What happens when you must have an account with some braindead website that requires a 6-8 character alphanumeric password? (Answer: you'll need either a secondary reconstruction algorithm, or a third salt and an alternate hashing algorithm that generates (possibly short) alphanumeric strings. You'll also need some mechanism for flagging the weak passwords.) You already have to remember 7 chunks of information to reconstruct the password (not counting the algorithm -- I'll assume for the sake of argument you have this automated). And it gets even worse, because after you've solved this problem, you'll come across an even more braindead service that requires a new set of recipes.

Another problem is the step of using the first half of the password "from the next line". If you lose the list, you can reconstruct the "word" pair for each site, but you won't be able to reconstruct the correct password unless you get the order of the sites correct. (IMO this step is an unnecessary obfuscation -- if someone has the list and knows the algorithm then there's no added value for you.)

And then you rely on hashing the "service name". What specific string are you using for this? The server name? What happens when MegaBank is aquired by GigaBank and your accounts move from wwws.mega.example.com to wws1.giga.example.com? I suppose it's easy enough to simply change your passwords when the service name changes, but it's another annoyance.

How do you handle forced password changes? One system I know of appears to remember your last two passwords so you can't reuse them. You could amend your scheme to include an 8th chunk of information -- a "sequence number"; this would be appended (or prepended, or inserted in some arbitrary position -- but this amount of variation amounts to remembering a 9th chunk of information). This becomes a hassle on systems that require you to change your password every 60 or 90 days.

How do you track usernames? Do you memorize them or are they written down?

What if you have multiple accounts with a single service? Your algorithm guarantees (by design) that a given service generates exactly one password. For example, perhaps you have to log into separate accounts at your bank or brokerage.

How are you storing the "very long password" used to generate the hashes? This has to be stored somewhere, separately from the password list.

If you have a more elegant solution that meets the design criteria, please share! I'd love to use it

I don't have another solution to fit your criteria.

At one time I used a reconstruction scheme based on website name and a couple of bits of information. It fell apart fast because of the reasons outlined above and I started using keepassx with a strong master password. Now, on each service I use a unique randomly generated maximum length password with the maximum allowed set of characters.

Your question outlines the risks associated with this system.

Edit: a single point of failure that I missed in my initial analysis is your email account. Unless you're using multiple independent email accounts, with a separate account for each service, your email is a single point of failure for multiple services because of the way most password recovery systems work. If your mail account password is compromised (social engineering, keylogger, etc), many of your services will also be compromised.

  • thank you for your sincere and detailed analysis. Many of your points have been addressed but I didn't add them because it was getting too long. But basically, point 1: don't use them or use a low grade recycled password. They are not holding anything valuable and if they are, don't use the service. Point 2: they are only written that way, generated as 1 line. Points 3 & 4: this is handled in the generating program. Point 5&6 username can be recorded as well, and hashed with the domain. Finally, long password: in memory with secure offline backup as it's only used to make the list – user5614 Oct 27 '11 at 1:49
  • 1
    @myq: "Don't use the service" -- sometimes you don't have a choice. – bstpierre Oct 27 '11 at 1:53
  • Very good break-down here. I especially like the note of your e-mail account being a single point of failure. – Iszi Nov 5 '11 at 14:30

While that technique may work for you, and will give you reasonable strength (from my quick skim through), the simple problem that at least 95% of the planet would have is:

It's way too complicated

Humans (generally) just won't remember those rules, and they'll lose the piece of paper

So while a quick answer to the specific question may be "it looks okay", its applicability is minimal.

  • 1
    The OP was a tl;dr for me, so I tend to agree. – Iszi Oct 26 '11 at 12:44
  • Whoa, there's 5% of the planet that could keep that scheme straight?? – bstpierre Oct 26 '11 at 13:27
  • 1
    @bstpierre - fixed that for ya :-) – Rory Alsop Oct 26 '11 at 13:37
  • 3
    @myq Length of an explanation does not make or break security, but it can make it difficult to understand how the system works, which increases the odds that somebody will mess up somehow negating the security of the system. – Steve Oct 27 '11 at 1:05
  • 3
    @myq Usability must be a primary goal of any system such as this one, otherwise the system will not be used or will end up being circumvented by many users. Once that happens, your primary goal is no longer accomplished. – Iszi Oct 27 '11 at 1:10

As noted this technique is too complicated and requires big amount of time just to enter the password (you need to remember salt, padding, divider and then consequently apply those to hash).

Why not use simple pass-phrases (of course different ones for different services) as suggested by xkcd (see also this question)? They have high entropy, are easy to remember and fast to type.

  • As noted in the 'why not diceware' part, that doesn't fit the design criteria. If you want a unique password for each service, you still need a way to store them. If you store them all in one place, then you have a single point of failure, which again violates the design criteria. The goal is to survive a failure of any one part and still have a secure list of strong passwords. That means at least 50% of the information can't be stored in the list. With diceware, that means you are going to have very long salt and very, very long passswords. – user5614 Oct 26 '11 at 23:00
  • @randomstranger - +1: One of my first thoughts here was "correcthorsebatterystaple". – Iszi Oct 27 '11 at 1:35
  • @Iszi that's good for one site. Now for all 20-30 that the average person needs to remember? – user5614 Oct 27 '11 at 1:50