Muliti-Password Systems

tatchley

Agile Staff, what are your thoughts on a Multi-Password System in which data is separated into groups and each group has its own password? In your endeavors to provide a password managing solution, I'm sure you have considered this idea at one point or another. Why did you opt to provide the current system? In my mind, although it would require a little more memorization, this method seems more "safe" because if a portion of the data was compromised it wouldn't necessarily compromise the other sets (assuming the compromised portion didn't include your email information, and further assuming that you didn't have two-factor identification in place, but that's another topic). While I have a Master Password that consisting of dice-words that for a password in the upper "Excellent" range of your scale, I have a nagging fear that someone will be watching over my shoulders and memorize my password (I think this is a greater threat than my computer being stolen and mercilessly being put through days of intensive brute-forcing, as you all like to joke about). I would be at-ease is I knew all my data was not tied to the same string, so to speak.

khad

The concepts of data sharing, multiple data files, and multiple security levels within 1Password have been suggested a number of times and they are certainly very interesting ideas. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



We have looked at these at various times, but any one of them would require some substantial changes to how 1Password works right now. The biggest downside I see (just speaking for myself here) is increased complexity and therefore a high barrier to entry.



I think Jeff's closing remarks in his "[url="http://blog.agilebits.com/2011/08/22/convenience-is-security/"]Convenience is Security[/url]" post are applicable here:



[indent=1]You may have met Wendy Appleseed. She is our sample user if you import our Sample data ([i]Help > Tools > Import Sample Data File[/i]). Wendy can get the full benefits of the top notch algorithms and protocols we use because we take her user experience very seriously; we see convenience as part of security. When we are presented with something that appears to be conflict between usability and security, we take that as a challenge. Meeting that challenge is hard work, but we love it.[/indent]



So while we never say never, we would have to be very careful in implementing such a design, and we would have to have some very good reasons to do so.



Thanks for letting us know you would be interested in such a fundamental change. It does help to know how many users are interested in some of these concepts that we discuss around the water cooler. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

jpgoldberg

This is a great question, tachley, but I don't think you will be happy with my answer



We designed our data format with multiple levels and layers in mind. So there are hooks within the actual data format for these. (Different items can be encrypted with different keys).



But Khad is absolutely correct. We've concluded at this point that the added complexity for users wasn't worth the gain in utility.



When a security tool gets too complicated for users, it becomes easier for them to make mistakes that harm their security. Our goal is to make it easy for people to do the right thing and hard for them to do the wrong thing. As a consequence we keep "advanced options" and the like to a minimum.



Of course all of these sorts of judgements about what adds too much complexity for too little gain for most people is something that can change over time. So your request for something like this does play a role in those judgements.



So your question is a good one, and please contribute other ideas as they come up, but I don't see us making this particular change in the near future.



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

http://agilebits.com

tatchley

Hmm, so it is a complexity issue. I can see how adding more complexity might increase security, but decease usability (and visa versa). As a user, I would suggest having the option there for those who want it, however that might compromise your ever-important usability factor while not giving enough gain to enough people. Not to mention, I'm sure you all would not like to code such a difficult addition when, to most people, 1P works fine right now.



One last question: Do you guys ever do polls? I would love to see how some popular suggestions compare vs. others. Monthly polls would be a good way to keep ideas fresh and let the users know that you are still considering suggestions.

khad

You are absolutely correct. We could make it an advanced option with lots of warnings, but we know that many people will always dial up security settings to 11 whether it is in their interest or not. 1Password is a mass market product. It's great that security geeks use and respect it, but we don't want to give our users rope to hang themselves with.



None of this is written in stone. That is just why, to date, we have not implemented multiple security levels in the UI. It's not an easy thing to get just right, and we think that it might do more harm than good. While there are no immediate plans add this, the door is always open to new possibilities in the future.



As for polls, we've found that polls can often take on a "poll-arizing" nature dividing folks into camps "fer and agains'" a particular request. We much prefer the freeform dialog that this community forum allows for so folks can present more nuanced views than a simple poll allows for. Hopefully our presence and response here serves as a strong indicator that we always take suggestions seriously. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

tatchley

While I agree that more detailed opinions that "yes," "no," or "maybe" are necessary to develop different perspectives on the same issue, I see no reason why these ideas cannot work in conjunction with a broader poll, and/or topic.



For example, you could create a topic asking for the opinions about a proposed enhancement. From there, users would choose the option that represents their beliefs and be encouraged to write a post briefly describing why they feel that way. The poll would provide a quick glimpse of the general opinion of users, while the users' posts would allow for a more detailed insight. Yes, the same result could be achieved by just making a new topic without a poll, but the poll synthesizes the ideas into a concise statement, easily viewable to everyone without having to delve into the many responses that would be sure to abound.



Also, with a centralized (perhaps also pinned) topic, users could add their two cents without worrying about it not being heard. Sure, each person will eventually get a reply from you guys, but the fact that they supported an idea in a topic that will most likely be buried and forgotten as others are created is a disheartening one, not to mention a counterproductive one. Amidst so many different individual ideas, how to you keep track of each person's? I don't mean to sound rude, but I find it hard to believe that you all would still hear my opinion that I posted, say, a year ago. With a single topic and/or poll, though, a person would not have to worry about not being heard.



Regardless of how you keep track of each person's ideas, a formal topic where people would know to post their opinions on a given topic would no doubt organize things and keep the ideas alive, especially if it was pinned. Instead of struggling maintain a bunch of loose papers, so to speak, a centralized topic would serve as a folder which stores and catalogues each post for future reference. Combined with a poll, you would have concrete data to refer to instead of generally saying "There has been recently been a strong desire to implement suggestion X."

khad

That is definitely one way to approach feature requests. Like [url="http://37signals.com"]37Signals[/url], we've found that it does not scale very well, so we tend to take the "[url="http://gettingreal.37signals.com"]Getting Real[/url]" approach. The [url="http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php"]section on feature requests[/url] is worth reading in its entirety — the whole book is — but this excerpt is particularly germane:



[indent=1]When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we'd update the list with an extra hash mark (II or III or IIII, etc). We figured that one day we'd review this list and start working from the most requested features on down.[/indent]



[indent=1]But the truth is we never looked at it again. We already knew what needed to be done next because our customers constantly reminded us by making the same requests over and over again.[b] There was no need for a list or lots of analysis because it was all happening in real time. You can't forget what's important when you are reminded of it every day.[/b][/indent]



So much changes in twelve months that year-old data is almost invariably irrelevant, and the parts that aren't are still coming up regularly. (I'll plead the fifth and not point to any specific examples, but I have a few in mind. That I have them in the forefront of my thoughts so readily is proof to me that the above process really does work.)



And, of course, in the very next section they include one of my favorite Steve Jobs quotes:



[indent=1]“[Innovation] comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important.”[/indent]

[right]—Steve Jobs, The Seed of Apple's Innovation[/right]



I don't mean to imply anything about the specific topic this thread started about, but I hope that addresses the broader meta-discussion which has emerged around it a bit. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



We really, truly value every bit of feedback that we receive, but to store it and analyze it in that matter becomes a job unto itself which can take away from what we really need to be doing (he says as he writes this post when he should be replying to customer support emails). To steal a phrase from Merlin Mann, it ends up being a bit like alphabetizing your recycling.



That's why we really do mean it when we say things like "keep the feedback coming." We can't forget what's important when we are reminded of it every day.



Cheers,

tatchley

I concede defeat. Your argument of a minimalist approach to feature implementation is undoubtedly stronger, in this case, than my more analytical method, although I still think there is value in statistical and systematic procedures. Perhaps this field does not suit it as well as others, though.



Besides, how can I win an argument with someone who has Steve Jobs on their side? <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

khad

Haha! I'm sure there are some teams — maybe larger corporations — for whom gathering much more data and analyzing it like that makes a lot more sense. We've conceded defeat to that approach and have taken the road less traveled. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

jpgoldberg

Please don't feel defeated, tatchley, as you concede defeat.



Sure we don't have systematics analytics of suggestions, but we do pay attention. There is a perceptual problem with running a poll or survey. It may suggest a promise to do what people vote for.



I started out as a "power user" of 1Password. A sophisticated user who came to 1Password after trying and failing to develop his own password management system. So I had loads of advanced capabilities to suggest "as options". But over time, I've really come to understand the virtues of the approach that Khad has articulated.



Overall, we want to keep things so that it is easy to use 1Password correctly and hard to use it incorrectly. That is something that will be considered heavily in everything we do.



Of course, it may be possible for us to do the kind of thing that you suggest without increasing the complexity or chances of people making life harder for themselves. If we find such a way, then we do pursue those.



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

http://agilebits.com