3 ms·

Universities are generally designed such that people following their natural incentives will get security wrong. Universities tend to have both central staff, a

Universities are generally designed such that people following their natural incentives will get security wrong. Universities tend to have both central staff, and departmental IT staff distributed amongst them. It works in the sense that departments with larger needs can fund their own hires, but they're often understaffed, underfunded, and report to (and are hired by) people who's general requirements are that systems operate either long enough to submit a grant proposal, publish a paper, lecture in front of class or submit final grades. Anything security related, like rolling out patches, is likely to interfere. This hypothetical won't fly: > 'Oh gee, we rolled out the latest version of firefox and now your lab's instructional java applet won't run. Sorry we didn't test that before going live. But we patched this weeks' bug. See you this time next week!' I figure until cybersecurity causes more outages than security lapses, the departmental system will continue to underinvest in security practices and overproduce botnets. Because of that division, central IT folks working in security have few levers they can pull or dials they can twist. It's been shown that universities have the most expensive password policies among policies observed. Think about that: you can execute a six figure trade using a password less secure than what you need to download a lecture video in Blackboard.

newman314 11y ago
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).
jcranmer 11y ago
I totally believe that university password requirements are the strictest. The general standards for a "strict" password are >N characters, 3 of 4 character classes required, and sometimes a blacklist of passwords. The standards for my university? The ones I figured out (they don't spell a guideline out for you until you violate it): * >N characters * 3 of 4 classes * No substring of >5 characters can match a dictionary word (which apparently includes "anita" o_O) * Can't have your name in there anywhere * No three consecutive characters can be the same or a run (so no 111, 123, 321, ghi, etc.) * Can't be any of your last 10 passwords * Please change every 9 months There's probably a few more that I haven't had cause to discover yet.

newman314 11y ago

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

jcranmer 11y ago

I totally believe that university password requirements are the strictest. The general standards for a "strict" password are >N characters, 3 of 4 character classes required, and sometimes a blacklist of passwords. The standards for my university? The ones I figured out (they don't spell a guideline out for you until you violate it): * >N characters * 3 of 4 classes * No substring of >5 characters can match a dictionary word (which apparently includes "anita" o_O) * Can't have your name in there anywhere * No three consecutive characters can be the same or a run (so no 111, 123, 321, ghi, etc.) * Can't be any of your last 10 passwords * Please change every 9 months There's probably a few more that I haven't had cause to discover yet.