0

I have read Sequential password updates and I am aware of a number of techniques to prevent users from using password variants. My question is, which of these techniques are actually used in user authentication in a Microsoft domain server? I am no expert in server software - what I mean is the (supposedly) common backend to user administration and authentication of login attempts to domain user accounts with Windows, Outlook, Outlook Web Access, which all seem (be able to) use the same data and enforce the same password rules, including prevention of re-use of substrings of historic passwords.

Is any hard information available from systematic tests? Has source code been leaked that drives this prevention of variations? Or what else is known? E.g., how many, or for how long back, are old password hashes stored? Which variants are pre-hashed and stored along a new password? What of that is fixed, and what is configurable by the administrators?

Background: I am an interested user fed up by having to change my password every 90 days without any reason. IT admins won't admit that's a nonsensical idea, despite recent NIST recommendations. It's not a terribly important account, so of course I resort to using password variants. I simply want to make my life easier by being able to predict which password variants are allowed - I typically spend 10-20 minutes in a quarter coming up with a new variant that's allowed.

bers
  • 200
  • 1
  • 9

2 Answers2

1

Windows domain password complexity is enforced by group policy, full info on what the 'password complexity' requirement means in windows is available here: https://technet.microsoft.com/en-us/library/hh994562(v=ws.11).aspx

but here's the highlights:

  • May not contain your username (the one you login with)
  • May not contain any part of your full name (There's a whole paragraph on the technet page defining what a 'part' means)
  • May not be one of X old passwords (the number X is configurable by admins)
  • Must be at least X characters long (number X is configurable by admins)
  • Must contain 3 out of 5 of the following categories
    • a-z (lowercase alphabet)
    • A-Z (uppercase alphabet)
    • 0-9 (numerical)
    • symbols/non-alphanumeric characters (!@#$%^&*, etc.)
    • extended Unicode characters (Chinese/Japanese characters, etc.)

Unless they've implemented a third-party solution there's no 'substrings of old passwords' option. My recommendation if you're interested in using the NIST passphrase recommendation, I'd choose a new passphrase each quarter, and then add on an numeric/symbol end (which can stay the same quarter to quarter).

e.g.

q1 : Jumpingtheshark382##@

q2 : Talktothehand382##@

q3 : He'sgoingthedistance382##@

etc.

K.B.
  • 677
  • 4
  • 6
0

Your Domain Administrators have most likely made decisions in line with industry best practices, or a security policy decision that's been made from a Security Governance perspective.

Many organisations define these settings using password complexity and history policies, however some ADDS organisations will use fine-grained password policies (though these are typically for administrators, or users with riskier levels of access).

Provide feedback to your IT Admins, so that they can consider user experience when designing services, and point them to the recommendations from NIST.

Keep in mind, that although the guidance has changed, that doesn't mean that your organisations risk level/appetite will automatically adjust accordingly (e.g., if you're not already supplementing domain logon with Multi Factor Authentication).

Qaos
  • 1
  • 2