3 ms·

Source on that statement about expensive password policies please?

jldugger 11y ago
Did you search at all because you were interested in the research, or were you just hoping to call that out as bullshit? Let's pretend for a moment you're genuinely curious. Florêncio & Herley of Microsoft research published a paper: Where do security policies come from? http://dl.acm.org/citation.cfm?id=1837124 http://dl.acm.org/citation.cfm?id=1837124. Their finding demonstrates that uni policies require more entropy. Cormac has done a lot of research on the subject of passwords, including a recent survey of the subject presented to usenix: https://www.usenix.org/system/files/conference/lisa14/lisa14-paper-florencio.pdf https://www.usenix.org/system/files/conference/lisa14/lisa14... Kelley et all at CMU used a mechanical turk study to collect a large set of passwords under different policies, and observe error rates, and password recovery requests. While they found that some policies were more effective at recall than others, the general trend is more entropy -> less recalled. Finally, experience. I worked as a programmer at a university, where I saw how this plays out: Internally, tickets are assigned a root cause; password resets were assigned to IDM, even though the system was working as requested. Helpdesks are typically 50-75 percent password reset, so we looked far worse than the rest of the teams. The Helpdesk manager is responsible for staffing helpdesk, but has no say on security policies. The CISO has limited budget, but can set policies. Our Identity Management software development team, responsible for enforcing password strength policies, password expiration notices, directory information, etc., met with both of these people regularly, and it became clear they did not. As Cormac points out, it's likely that .com policies are simpler, because they have to attract and retain customers. It seems likely .com measures bounce rates for signups, and universities that have an adwords campaign had policies closer to .com than .edu. I forget if we measured bounce rates, but we did implement a system to track how many tries it took for people to produce a valid password. This was a while ago, and I switched to server administration shortly after this, but I recall the statistics being roughly an average of 2 tries, maybe more. Meanwhile, the security team actually ding'd us for providing a realtime feedback of whether the password field was or was not in the dictionary, in line with the rest of the real time policy checkers they requested (3 of 4 character categories, 9 characters long, etc).

Did you search at all because you were interested in the research, or were you just hoping to call that out as bullshit? Let's pretend for a moment you're genuinely curious. Florêncio & Herley of Microsoft research published a paper: Where do security policies come from? http://dl.acm.org/citation.cfm?id=1837124 http://dl.acm.org/citation.cfm?id=1837124. Their finding demonstrates that uni policies require more entropy. Cormac has done a lot of research on the subject of passwords, including a recent survey of the subject presented to usenix: https://www.usenix.org/system/files/conference/lisa14/lisa14-paper-florencio.pdf https://www.usenix.org/system/files/conference/lisa14/lisa14... Kelley et all at CMU used a mechanical turk study to collect a large set of passwords under different policies, and observe error rates, and password recovery requests. While they found that some policies were more effective at recall than others, the general trend is more entropy -> less recalled. Finally, experience. I worked as a programmer at a university, where I saw how this plays out: Internally, tickets are assigned a root cause; password resets were assigned to IDM, even though the system was working as requested. Helpdesks are typically 50-75 percent password reset, so we looked far worse than the rest of the teams. The Helpdesk manager is responsible for staffing helpdesk, but has no say on security policies. The CISO has limited budget, but can set policies. Our Identity Management software development team, responsible for enforcing password strength policies, password expiration notices, directory information, etc., met with both of these people regularly, and it became clear they did not. As Cormac points out, it's likely that .com policies are simpler, because they have to attract and retain customers. It seems likely .com measures bounce rates for signups, and universities that have an adwords campaign had policies closer to .com than .edu. I forget if we measured bounce rates, but we did implement a system to track how many tries it took for people to produce a valid password. This was a while ago, and I switched to server administration shortly after this, but I recall the statistics being roughly an average of 2 tries, maybe more. Meanwhile, the security team actually ding'd us for providing a realtime feedback of whether the password field was or was not in the dictionary, in line with the rest of the real time policy checkers they requested (3 of 4 character categories, 9 characters long, etc).