On Dec 9, 2013, at 7:23 AM, Adam Rogers <[email protected]> wrote: > This is a very interesting set of problems to solve. > > 1) My password is not secure enough > 2) My password is too difficult to remember > 3) My password is too difficult to type > > I'm not sure a blacklist is the right approach. If someone really wants to > use their first name as their password that's up to them. But, if they're > using their first name because they can't think of something better, that may > be an area where we can help. What ideas do people have?
My idea: try to measure the impact of doing something before devoting significant resources to doing it. Adam suggests a two camps when a user chooses a lousy password: 1) Users who intentionally want that lousy password (e.g., because it's a low value site, they want to remember it, or they just don't care). 2) Users who are generally open to security education to improve their password. If 99% of lousy password choosers are in camp #1, I would argue that we shouldn't invest much into this effort. What's the actual percentage? I have no idea. FWIW, security user education rarely works [1], usually because the cost/benefit or value prop isn't sufficiently high or isn't obvious. We wouldn't be the first people to try to improve this situation, and unfortunately, the results by others thus far have been underwhelming. Parade raining aside, this is an enormously complicated issue, with variables that are both difficult to measure and vary from user to user. For example, what is the shortest bank password a user with: 1) X1 level of technical competence 2) $X2 in the bank 3) A bank that offers $X3 of liability protection against fraud 4) A bank with X4 level of additional fraud detection in place 5) X5 disgruntled ex-boyfriends choose so that the chance of loss/pain is "sufficiently" low? I have no idea. Typically, the thing we as security professionals do is to "assume the worst" [2]. We offer up arcane rules and steps to choose a strong password without taking into account the rest of the user's situation and risk profile. This is often called "worst case thinking", and it's typically not very effective for security problems that have mushy variables (e.g., terrorism prevention) [3]. Users typically don't know all those variables either, but they have a hell of a lot better of idea than we do for many of them. They make a guess of what kind of password they need. And the service providers manage risk and deal with fraud. And the world is not on fire [3]. And my wife's right, build tools that don't overly burden users with the hazard: password managers (that generate passwords) and 2-factor auth. -chris [1] http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf [2] What else can reasonably do? We can't feasibly measure the cost/benefit for each user. [3] It's great for cryptography and network security protocols, though. [4] Yet. > ----- Original Message ----- > From: "Ryan Feeley" <[email protected]> > To: [email protected], [email protected] > Sent: Monday, December 9, 2013 10:08:34 AM > Subject: 10,000 Top Passwords (cross post) > > (Sent earlier to dev-identity list, but relevant to you all as well.) > > "91% of all user passwords sampled all appear on the list of just the top > 1,000 passwords." > > https://xato.net/passwords/more-top-worst-passwords/#.UqWy83i9LCS > > If true, it's hard to argue that passwords alone are strong enough to secure > accounts. Create a blacklist? I would love to help people concoct their own > password scheme and improve password management at the same time. > > Ryan Feeley > Product Designer, Identity > Mozilla UX > IRC: rfeeley > > > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
