How can we improve Azure Active Directory?

Allow Long Passwords

the current max password is 16 chars, please make it larger

Longer is (Usually) Stronger section

source of current max length:

510 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)

We’ll send you updates on this idea

Mike DePouw shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Gabriel commented  ·   ·  Flag as inappropriate

    I am surprised and disappointed by Microsoft in this. Come on, folks. It's 2019, a sixteen character maximum is totally nuts. All good security practice allows for phrases for passwords, and by limiting them in this way, you make security worse!

  • Sven commented  ·   ·  Flag as inappropriate

    This restriction interferes with Safari's "Strong Password" feature. It is also worrying that such a limit even exists this day and age, especially given what kind of resources these passwords potentially protect.

  • Alexander Martin commented  ·   ·  Flag as inappropriate

    The fact that this restriction exists, and that it has gone unchanged for so long after numerous requests to remove it, casts serious doubt on the architecture of password storage for cloud-native Azure AD users. Such a restriction likely indicates that passwords are either being stored in an insecure manner, such as plain-text or two-way encryption, that is length sensitive, or that password hashes are computed in a highly incorrect manner that limits input length. I am forced to question if cloud-native accounts' passwords are even stored in a secure manner.

    No other modern directory or authentication service of which I am aware imposes such a strict and disconcerting restriction on passwords. The fact that passwords synced from AD DS are subject only to AD DS's password policies causes even further confusion, as it would seem to indicate that it is possible to handle longer passwords in Azure AD's backend, yet this capability is not available to cloud-native accounts. Again, this casts serious doubts on the Azure AD's password storage architecture.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Have just discovered that in addition to the length restriction "feature", that /spaces/ will not be accepted as passwords. I'm lost for words.

    Moreover, this is no actual indication of this when setting a password. I continue to be astounded as to how absolutely p**s-poor this insane password policy is. This should have been laughed out of the meeting room at the first possible opportunity.

  • Anonymous commented  ·   ·  Flag as inappropriate

    This should not be a feature request. It's not a feature, it certainly should not have to be requested. I'm frankly speechless. There is no good reason on this earth why this limit should exist in this day and age. I'm inclined to believe the 5-eyes crackability theory, in absence of any other credible reason.

    Currently resetting passwords following a decidedly tiresome migration from G-Suite, and I'm currently regretting performing that migration.

    This is supposed to be a grown-up business tool, not jazzed up copy of Hotmail sold to business users.

    Fix it, Microsoft. Fix it yesterday. This would currently cause our business to fail NCSC requirements. If this isn't resolved /very/ quickly (unlikely given the "Yeah, we're looking at it" post way back in March) then I'll be strongly recommending a migration back to G-Suite - for all it's warts and prying, they at least appear to understand elementary security principles.

    The disruption is moot since that's precisely what this "feature" is about to cause for the entire userbase I'm migrating.

  • Anonymous commented  ·   ·  Flag as inappropriate

    This needs to happen ASAP. It's such an annoying and stupid restriction anyway - the passwords are salted and encrypted - the length doesn't matter - they're all the same length in the database anyway!

  • T. K. commented  ·   ·  Flag as inappropriate

    If you are storing hashed passwords, the length of the password itself doesn't matter. It's just a web input field. How can this be in considering/planning phase for eight months?

    Unless you are storing passwords in plain text and the password column is actually 16 characters. In which case, holy **** all the cloud naysayers were right.

  • Jo commented  ·   ·  Flag as inappropriate

    Is it possible to configure the minimum password length to ... more than 8?

  • Anonymous commented  ·   ·  Flag as inappropriate

    Why do we actually need to vote for this? This should be a OOB feature.
    For some reason this also limits our on-premise AD which does password hash synchronization using Azure AD Connect. Users in on-premise windows AD cannot set password with more than 16 characters...I don't really understand why that is.
    MS support is useless.

  • Anonymous commented  ·   ·  Flag as inappropriate

    NIST and Microsoft (since early 2000's) have suggested passphrases. The issue is that Microsoft has failed to make the cloud as secure as on-premises. Many of the controls for passwords, even the newest password controls such as "deny lists" are far from where things need to be. Granted, "deny lists" don't exist on-premises from Microsoft (ok, via a proxy), but other organizations have provided robust password controls for on-premises AD for years.

    The key is to know the limitations and work within the confines.

    A 16 char maximum password is not secure... no matter "who" says it is. We all can come up with a list saying that 16 is weak compared to 20+

  • Steve Catlin commented  ·   ·  Flag as inappropriate

    Wow.... This is just pathetic. It honestly never occurred to me that this would be in issue in 2018. Every MS rep on Earth is pushing everyone to AzureAD as hard as they can and it doesn't even support a reasonable PW policy.

  • Timothy commented  ·   ·  Flag as inappropriate

    I'm surprised this is still an issue on AzureAD. Microsoft should be embarrassed since they actually do so well protecting credentials in other areas. Active Directory on-premises (ADDS) has allowed 127 character passwords since the year 2000!

  • Jared Thirsk commented  ·   ·  Flag as inappropriate

    How are we supposed to take Azure AD and Microsoft seriously if there is a low and seemingly arbitrary cap on how secure passwords can be?

  • Anonymous commented  ·   ·  Flag as inappropriate

    This could cause problems for UK customers trying to get certified under the UK Gov Cyber Essentials scheme, see
    Secure Configuration section:
    "Password-based authentication
    The Applicant must make good use of the technical controls available to it on password-protected systems. As much as is reasonably practicable, technical controls and policies must shift the burden away from individual users and reduce reliance on them knowing and using good practices. [...]
    For password-based authentication in Internet-facing services the Applicant must: [...]
    not set a maximum password length"
    So as far as I can tell that's a big fat fail for Azure AD at the moment. If multi-factor auth isn't being used.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Why in the world is this still a thing?!? There is zero justification for KNOWING that your lowering your customers security and continuing to not correct the issue. Microsoft's disregard for limiting the security strength of its customers passwords is disgusting.

  • Mark R commented  ·   ·  Flag as inappropriate

    This remains an issue?! How can any security professional at Microsoft look at themselves in the mirror in the morning with such a simple and obvious security that, apparently, is not a priority?

    My organization has to curtail our security enhancement plans because Microsoft cant keep up with what's best practice?

    Microsoft goes on and on about the security of the "Microsoft Cloud." Really?

    Does anyone with any authority at Microsoft ever even read this?

  • Shane commented  ·   ·  Flag as inappropriate

    We've been able to use 127-character passwords since Windows 2000, whatever the fundamental limitation is behind this really needs sorting out.

Feedback and Knowledge Base