How can we improve Azure Active Directory?

Allow Long Passwords

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

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

Longer is (Usually) Stronger section

source of current max length: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-policy

483 votes
Sign in
(thinking…)
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

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

54 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Magruder Administrator commented  ·   ·  Flag as inappropriate

    Per NIST guidelines, increase the password length. Up to 64 characters would be optimal.

    SP 800-63 Digital Identity Guidelines
    https://doi.org/10.6028/NIST.SP.800-63-3

    SP 800-63A Enrollment and Identity Proofing
    https://doi.org/10.6028/NIST.SP.800-63a

    SP 800-63B Authentication and Lifecycle Management
    https://doi.org/10.6028/NIST.SP.800-63b

    SP 800-63C Federation and Assertions
    https://doi.org/10.6028/NIST.SP.800-63c

  • Anonymous commented  ·   ·  Flag as inappropriate

    Here's another comment on the ridiculousness of the password complexity limitations in Azure AD.

  • Anonymous commented  ·   ·  Flag as inappropriate

    How is Microsoft planning on the move to Azure AD if it still requires an on-prem AD just to have proper password policies..... Not to mention I have no power over Local passwords with Azure AD, even with the use of Intune.

  • Tao commented  ·   ·  Flag as inappropriate

    Let us use our own passwords.. I have three, well had three passwords i used sense 1999.. Random letters and numbers i memorized.. Now i am not allowed to alternate my password and now have to save them in my phone.. Now its super insecure. I conplained to Microsoft directly to be told use finger print.. Oh thays even easier to get someones finger print, how about log into person account with a picture fron there account.. Why is everyone makimg it easier for people to hack into your account, just because you say its better, dont mean it is... Up until last two years had no issues, now i have issues all the time with my account.. Let me be in control of my account, let me have my own personal password i dont have to save in phone or write down.. I bet i could call anyone in Microsoft say my password and none of them would still not get it right.. My new password well is easy to fivure out and guessing i willl have to switch to another company because I lost my mac (iphones over password) lost my Google account and now i will be losijg my Microsoft account, guess i will be joining the Chinese internet or Russian apps because American companies have no clue how to keep our accounts safe, only makong it easier to hack by making us change passwords every 6 months and forcing us to save in new floders with all our account passwords.. Guess its easier for them to track us and get all our info including access to our accounts /sell access to other companies or whoever...

  • Anonymous commented  ·   ·  Flag as inappropriate

    I really hope you will also allow customers to getting rid of the mandatory requirement of using 3 out of the 4 character sets. That policy is so 90s and just leads to users creating stupid passwords like Password123 while it doesn't allow using secure ones like bluegoatdollechopox

  • Daniel commented  ·   ·  Flag as inappropriate

    We do not have on prem AD. Please correct this horrendous error in judgement on Microsoft's part and allow our users to better protect themselves. From: https://docs.microsoft.com/en-us/office365/enterprise/protect-your-global-administrator-accounts - "You own your data and identities and the responsibility for protecting them, the security of your on-premises resources, and the security of cloud components you control." No Microsoft, apparently I cannot control the security. Even Global Admins are restricted to 16 characters.

  • Rob Wilderman commented  ·   ·  Flag as inappropriate

    I am encouraging everyone to do as I plan on doing and complain about this issue weekly to 365 Support until it gets resolved. This text does not cause enough pain on this issue. We need to start being a really really squeaky wheel. If we all open a ticket weekly, then it is cutting into MS bottom line, and they will need to listen.

  • Rob Wilderman commented  ·   ·  Flag as inappropriate

    Some major operating systems are now suggesting strong passwords that go beyond the 16 character length. Apple's Safari password vault suggests 25 character passwords for example. It is confusing and disheartening to our users who are trying to put in to practice what we have been preaching about password security to them, to have an error pop up when they try to use a more secure password. Yes we can change the password on Premise, and then synchronize it at the next ADSyncCycle, but a user should not have to wait to start using their e-mail again for a pre-determined period of time after changing their password. This is unacceptable. I cannot imagine why this seemingly arbitrary limit was put in place to start with in the Cloud. Microsoft's cloud products should have remained compatible with On-Premise products at all times.

  • Daniel Rollins commented  ·   ·  Flag as inappropriate

    I'm with everyone else on this, how in the world do we have a 16 char max and no spaces? Regular AD has allowed both for years because it is more secure. Did they just copy the Azure password system from some really old code? Get with the program MSFT, how long can it possibly take to increase the max to something reasonable, like maybe 64, and allow spaces? I still can't believe this actually went public in its current state.

  • Roger Seekell commented  ·   ·  Flag as inappropriate

    Yes, Pass-through Auth is fine for most, but we have cloud-only accounts that need to have more-secure passwords/passphrases.

  • Timmy commented  ·   ·  Flag as inappropriate

    We are 10 months now from "the team is aware of this feedback and is in considering/planning stage."

    I know you guys work hard and have tons of deliverables, so there is clearly enough developers to fix this issue and fix in a reasonabel time frame. I see the new feature announcements every couple weeks.

    Management needs to prioritize these very serious, very basic security concerns and stop just paying lip service to them with "we are aware" feedback. It is completely ridiculous that enterprise customers have to wait YEARS to have issues addressed. This isn't the only one. These feedback forums are stuffed to the gills with issues that Microsoft is "aware of" but are too busy chasing the latest shiny new feature rather than finishing their existing features.

    The cloud promised so much, but all it ever seems to deliver at the end of the day is high costs, delays, and downtime.

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

← Previous 1 3

Feedback and Knowledge Base