On 14/10/2013 20:23, Tanstaafl wrote: > On 2013-10-13 4:07 PM, Martin Vaeth <va...@mathematik.uni-wuerzburg.de> > wrote: >> Like passwords, these sequences should better not stay the same for >> too long... > > Forced changing of passwords (and I imagine the same can be said for > port-knocking sequences, which I've never implemented, but am intrigued > by, although I tend to avoid security-through-obscurity schemes) > periodically as a way to 'better security' is one of those myths that > just never seem to go away. > > Enforce strong passwords and a policy that no one is to ever write a > password down and put it in any publicly accessible place, and educate > users how not to fall for phishing attacks, is the single most effective > way to keep things secure. > > Then only change a password if/when an account is compromised.
Here here. I fully agree, and I have a use case to back you up. Yes, it's anecdotal and just my use case, but at least it's factual :-) Access to my backend network is two-factor - ssh keys and decent passwords. I generate the passwords in code, they have high randomity but rememberable and I refuse to implement password expiry. People with sensitive and powerful accounts have enough head smarts to know when to tell me quietly they need a reset done, and everyone is happy with this. they don't mind that I see their passwords once in plaintext, as I can make the password anything I want anytime I want. The user's security against me comes via the HR department backed up by employment law. We have pentesters that exhaustively test stuff every few months. I insist they have full access to my data, supervised by the very trusted Risk guy, as I want them to find any weakness as opposed to the bad guys finding them. In 5 years they have cracked one password once out of many hundreds. One. It's an isolated case and I know how it happened - I trusted someone and bent one rule once. Contrast the scheme used by Windows. It uses every one of these "best practice" tricks inccluding expiring every 30 days, password length, complexity, special chars etc. With every audit it gets blown wide open, usually within a few hours. reason: human being are almost uniformly bad at selecting and maintaining passwords. I break all the best practice rules and have never have a systemic compromise in 5 years despite awesome tools weilded by real pros with clue throwing the book at it. Hmmm. The other system that does obey best practice gets ripped to pieces with trivial ease by the same guys. Hmmmmmmmmmmm. I can pull this off because a) few people dare go up against me and my facts :-) and b) it's a controlled environment. Obviously this couldn't work on a public service like say gmail. > > This combined with intelligent rate-limiting (with > notifications/warnings to admins if/when a users account exceeds them) > is all you need. > > In fact I go one step further... I assign passwords, and do not even > allow users to change them. I have always done this, and we have people > in this office that have had the same email password (on the same gentoo > server) for 12+ years. > > I know that I'm probably the exception to this rule, and it is more luck > than anything else, but we have never had an email account hacked (knock > on wood). > > I'm certainly not saying we are immune, but the claim that passwords > should be forcibly changed for no reason other than the passage of some > arbitrary amount of time is just plain dumb. > -- Alan McKinnon alan.mckin...@gmail.com
