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