(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed
Posted by Jorge on 2019-08-01
Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.
–
Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):
- Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
- Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
- Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
- To generate password you can use for example: https://passwordsgenerator.net/ which supports pre-configured URLs such as
- Generate Pwd (010 – No Symbols)
- Generate Pwd (015 – No Symbols)
- Generate Pwd (016 – No Symbols)
- Generate Pwd (016 – With Symbols)
- Generate Pwd (020 – No Symbols)
- Generate Pwd (020 – With Symbols)
- Generate Pwd (030 – No Symbols)
- Generate Pwd (030 – With Symbols)
- Generate Pwd (064 – No Symbols)
- Generate Pwd (064 – With Symbols)
- Generate Pwd (128 – No Symbols)
- Generate Pwd (128 – With Symbols)
- Generate Pwd (256 – No Symbols)
- Generate Pwd (256 – With Symbols)
- Move service accounts in AD from regular service accounts to:
- Group Managed Service Accounts if possible
- …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
- …and if that’s not possible keep using regular service accounts with long and unique passwords
- If possible, increase the password length to a minimum of 15 characters for users
- Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
- Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
- Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
- Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
- When using ADFS, implement extranet lockout policy
- Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
- Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
- Decrease the use of passwords as much as possible by:
- Implementing SSO
- Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
- Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)
–
Additional Resources:
- What is password-less?
- Password-less Strategy
- Password-less Protection (White Paper)
- A world without passwords with Azure Active Directory
- Enable password-less security key sign in for Azure AD
- Enable password-less sign-in with the Microsoft Authenticator app
- Windows Hello for Business
–
Hope this helps you!
–
Cheers,
Jorge
————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-
This entry was posted on 2019-08-01 at 20:14 and is filed under Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
One Response to “(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed”
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
J K Birks said
With both Google and Microsoft adding their weight to the Fido alliance (and with google even branding and marketing their own security key), we are finally seeing some positive signs of acceptance for the hardware that is required for passwordless authentication. Microsoft hello is now available across many platforms, and security keys/hardware tokens are now quite affordable, but we still need more people to switch to implement two factor authentication before we see the final switch to paswordless solutions.
LikeLike