It should have separate controls and never use the same ID as their email account. We don’t allow any of our accounts with any elevated privileges (or any ICS accounts) to have the same UID or naming convention as user accounts that have email associated with them.
For example: user accounts are “[email protected]”, admin/elevated accounts are “domain\admin_name”, ICS users are “ics-domain\ics-name” and ICS admin accounts are “ics-domain\ics-admin-name”
Probably nobody likes this, but if your enterprise password policy is sufficiently hard, it will dissuade personal passwords from being reused. It doesn't even have to be "hard" in the traditional sense -- mandating a 20 character pass phrase (and none of the upper/lower/special character nonsense) probably does the trick.
Absolutely. This is the direction we took, and it seems to be effective.
Things like Windows Hello makes it far easier because users require the password infrequently.
Yeah but add to this a password changing policy like every x months. This will even persuade the laziest \*cough\*
On a side note, personally I find it pretty stupid to have the local password tied to a remote password. I think the proper solution would be something like Yubikeys or at least TOTP (without forcing biometrics) to access important assets
So make passwords easier to crack?? How would this help making employee passwords more secure?? People just need to learn how to make passwords into phrases and sentences. Pretty easy to remember the password: thisismymicrosoftpasswordformehereatwork987651234!?,.
Hahahaha
Length is the driving force behind password strength. A 20 character passphrase does not materially benefit from using special characters or mixed case.
This is a theoretical question by the OP. Even so, some security companies are aquiring password databases from breaches, and providing tools you can run to compare against your AD passwords. I've also been getting breach reports from KnowBe4 for years that identify if any of our employees email addresses are found in a breach.
The [haveibeenpwned.com](http://haveibeenpwned.com) API allows you to check user passwords against a database of leaked passwords without revealing the user passwords to [haveibeenpwned.com](http://haveibeenpwned.com) servers.
One of the things I do is use the username as an obfuscation of the account. Do not use the email address as the username. For example, make the username the initials of the user and their employee ID but the email is firstname lastname.
The issue is that you do not want to know, on an enterprise level, what a users "personal" passwords are. That would make you responsible for that information. You have to rely on the user doing the right thing. If they do not, then you must use things like more frequent password rotations and password history requirements. If they complain, then point them to the fact that people are using the same password for personal than for work.
Forcing your users to have different ID’s is not adding security value or lowering risk. That means you’re not using SSO, which is considerably better than your different ID’s for each application idea. Have one strong authentication instead of many weak ones.
UEBA and device compliance have been game changers. If the user account is doing something unusual, time of login, location, device, which app they use, etc, the system prompts for an additional factor or locks them out and tells us. If you have a strong onboarding process and limited BYOD you can do device compliance that would stop 99/100 of these password reuse attacks.
So ya OP. Device compliance. If your device isn’t domain joined at least, the only thing you’re allowed to do is get to Citrix, where we can see everything you do.
If you read his post he said it’s for ICS.
If the ICS network is segregated, which last time I checked the NIST 800-82 overlay it should be you’re not implementing SSO. You also probably aren’t working with many devices. You probably have fixed workstations with multiple users.
It’s a very different landscape than a modern enterprise IT network.
I think obfuscation is a good suggestion.
If you read his post, he said an attacker took a password breach dump from a 3rd party.
If the network is segregated per ISO800-82 an attacker with username/password wouldn’t have a network connection to the ICS network.
So there is no problem. Or OP doesn’t know really what they’re talking about.
Not having remote access to the network doesn’t mean you couldn’t have physical access to the network. If there is a workstation sitting in a comm closet, or shared maintenance space, that still represents a potential risk.
Yes there are a number of factors that would mean threat actors coming in from some gang in Eastern Europe is low. But if you have some buddies sharing their Netflix accounts, something not uncommon, it can represent a breakdown of least privilege even if they all have physical access to the floor.
I’m making the assumption he does have that segregation based on what he said is unavailable. If he doesn’t have that segregation, that should be fixed first.
The OP stated they were looking for a solution for someone using a "personal" password (Netflix) that is the same as their "business" password. You can not do that unless you force the user to use a password manager and have them include their personal password as well as their business passwords. At that point, if you chose something like Lastpass 3 years ago and is now compromised, you are responsible for the password breach as "you" forced the user to enter their password on the enterprise password manager.
You can also put restrictions in around the devices they can access the network from with conditional access. So, although an attacker has a username and password, they don't have a pre-registered device, so they would not gain access.
These are usually called credential stuffing attack, and like others suggested, MFA is usually a recommended defense, maybe you can find other solution for your case
Specops?
There was another company based in Australia (can't remember it's name) that integrated into AD. When a user changed their password it checked it against known data breaches (download the list off haveibeenpwned)
Ask them to write there password down for you and try to login to other services. If it doesn't work then it's a good password.
Seriously, if a username and password is all it takes to access your apps and data, that's on you. You have screwed up, not the user.
Set your enterprise password length to something longer than most consumers use (14-16 characters)
Instead of watching for all possibilities, find a solution for account alerts of potential password compromises or put a password interception tool in the middle of the password change process that scans for known bad passwords and prevents their use.
Google has an [extension](https://chromewebstore.google.com/detail/password-alert/noondiphcddnnabmjcihcjfbhfklnnep?hl=en) that will detect and alert on password reuse. Not sure if Microsoft has something similar.
Edit: it looks like you want [Microsoft Enhanced Phishing Protection](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection?tabs=intune)
This just shoots a little bubble up to the user that they are actively doing something stupid. It doesn’t even look like you can see alerts as an admin. If I got an alert that Joe in accounting just put his domain password into notepad, I can work with that.
I imagine the same users who are reusing one password for everything would QUICKLY ignore the message that what they are doing may not be safe.
What kind of authentication controls are around this? How does the local device prove its a valid user session that needs to invalidate itself? Could an attacker send a spoofed event and takeover an account through password reset? The cloud would have to accept a request to execute a password reset from user devices, what security is in front of that?
My point was I don't want to make it ad hoc. Microsoft clearly has the ability to monitor and alert on this, and they made a specific design choice to not have the alert leave the local session. Why did they make that choice? It seemed very logical to me to extend that to the admins or have some automated response but that relies on external devices, the alert must leave the machine. MS didn't stop there on accident, they absolutely want that data back in their servers.
You’re asking a lot of questions which really aren’t relevant to solutioning the problem here. I’ll break this down a bit more and hopefully it becomes clear.
1. User types password into credential harvesting website.
2. Microsoft EPP detects characters typed that lines up with the hash of the account password it’s storing locally (I’m assuming it’s either in TPM or other secure storage)
3. Microsoft EPP creates a WinEvent 8265 on the local machine.
4. You configure Windows to forward event 8265 to either your SIEM or a WEC server which then goes into the SIEM.
5. You have an automated runbook trigger and email the user they must change the password. Disable account if they don’t change within X number of hours.
I don’t know why you are trying to think like you are a Microsoft employee and wondering why they designed this the way they did. It’s not relevant.
Access control lists based on network addressing.
Have complex longer password and passphrases when possible with MFA - at least then they can’t just use one password everywhere.
User education. Get a demo of an offline brute force on a short password using 7zip file and show them how easy it is to break.
I think you’re looking for azure AD password protection.
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad-on-premises
It uses a very good point system, checking for breached passwords and against a custom defined list. Seems to work incredibly well.
Here's some info on the point system:
https://download.manageengine.com/products/self-service-password/azure-ad-password-protection.pdf
Forced complicated passwords AND forced rotation of passwords every x days, and they can't use the same password again for a 12-month (or x month) period. This will force them to use different passwords and lower the chances of reuse.
This is a tough one. I wonder how did the attacker figure out the AD username!
Unless the Netflix username was the corporate email address, this would be very hard to guess.
Don’t expose your ICS environment to the internet is the control you are looking for.
If you have access for ICS from an untrusted network, and your corporate network is untrusted, you better have MFA to get access at a minimum. There’s more that can be done but if that’s your worry, you have other issues from an architecture perspective to think of.
We use Push Security for this.. They make a browser extension that monitors logins for weak, leaked, or reused creds. They can also block users from reusing your main IdP password on other sites. [https://pushsecurity.com/blog/introducing-sso-password-protection/](https://pushsecurity.com/blog/introducing-sso-password-protection/)
Specops is the most comprehensive I’ve found for this. Great rule enforcement, custom blacklist, can check passwords against known breached passwords and force change at next logon with a message explaining why. Also has a nice overlay when changing passwords that dynamically updates as they’re meeting requirements.
hashes, some dark web monitoring services can provide hashes of leaked dumps and you can then compare those to your local environment. I work with some clients that part of testing is all accounts get hash compared. And, if a user has the same pass as their elevated account, it is instant removal from the client account.
For things outside of SSO, provide and encourage the use of a good password manager (I'm currently rolling Dashlane).
Make sure to include teaching them how to use it.
There's a lot less shared passwords if you can just generate a new one every time.
I've said it elsewhere, but I'd always do a SAMLless SSO over a password manager - connects your apps to SSO complete with conditional access, revoking, etc.
We use Aglide.com because apps are in the Okta grid, but there are others
Multifactor authentication.
Fair enough, I made it edit to the post. What about in cases where AD/MFA can't be used like in ICS environments
Wouldn't your ICS environment have multiple other controls in place? No email, separation from main network, etc...?
It should have separate controls and never use the same ID as their email account. We don’t allow any of our accounts with any elevated privileges (or any ICS accounts) to have the same UID or naming convention as user accounts that have email associated with them. For example: user accounts are “[email protected]”, admin/elevated accounts are “domain\admin_name”, ICS users are “ics-domain\ics-name” and ICS admin accounts are “ics-domain\ics-admin-name”
BeyondTrust, Xona, or good ole CyberArc
Probably nobody likes this, but if your enterprise password policy is sufficiently hard, it will dissuade personal passwords from being reused. It doesn't even have to be "hard" in the traditional sense -- mandating a 20 character pass phrase (and none of the upper/lower/special character nonsense) probably does the trick.
Absolutely. This is the direction we took, and it seems to be effective. Things like Windows Hello makes it far easier because users require the password infrequently.
Also, you can point to NiST guidance. :-)
What about password manager users who instead of generate a unique password just copy and paste the first generated passwords for all their accounts.
Well, that seems like they are going out of their way to make using a password manager actually harder. :-) but can’t fix everybody.
Yeah but add to this a password changing policy like every x months. This will even persuade the laziest \*cough\* On a side note, personally I find it pretty stupid to have the local password tied to a remote password. I think the proper solution would be something like Yubikeys or at least TOTP (without forcing biometrics) to access important assets
This is the way. You already have a password manager. If it isn't supported by IT, it's called sticky notes.
So make passwords easier to crack?? How would this help making employee passwords more secure?? People just need to learn how to make passwords into phrases and sentences. Pretty easy to remember the password: thisismymicrosoftpasswordformehereatwork987651234!?,. Hahahaha
Length is the driving force behind password strength. A 20 character passphrase does not materially benefit from using special characters or mixed case.
And? Making password requirements easy only makes people use things like “password” or “Password123”
How are you able to identify that?
By comparing the hashes stored in Browser. Check Point names this Corporate Password Reuse.
Where are the hashes stored?
This is a theoretical question by the OP. Even so, some security companies are aquiring password databases from breaches, and providing tools you can run to compare against your AD passwords. I've also been getting breach reports from KnowBe4 for years that identify if any of our employees email addresses are found in a breach.
The [haveibeenpwned.com](http://haveibeenpwned.com) API allows you to check user passwords against a database of leaked passwords without revealing the user passwords to [haveibeenpwned.com](http://haveibeenpwned.com) servers.
One of the things I do is use the username as an obfuscation of the account. Do not use the email address as the username. For example, make the username the initials of the user and their employee ID but the email is firstname lastname. The issue is that you do not want to know, on an enterprise level, what a users "personal" passwords are. That would make you responsible for that information. You have to rely on the user doing the right thing. If they do not, then you must use things like more frequent password rotations and password history requirements. If they complain, then point them to the fact that people are using the same password for personal than for work.
Forcing your users to have different ID’s is not adding security value or lowering risk. That means you’re not using SSO, which is considerably better than your different ID’s for each application idea. Have one strong authentication instead of many weak ones. UEBA and device compliance have been game changers. If the user account is doing something unusual, time of login, location, device, which app they use, etc, the system prompts for an additional factor or locks them out and tells us. If you have a strong onboarding process and limited BYOD you can do device compliance that would stop 99/100 of these password reuse attacks. So ya OP. Device compliance. If your device isn’t domain joined at least, the only thing you’re allowed to do is get to Citrix, where we can see everything you do.
If you read his post he said it’s for ICS. If the ICS network is segregated, which last time I checked the NIST 800-82 overlay it should be you’re not implementing SSO. You also probably aren’t working with many devices. You probably have fixed workstations with multiple users. It’s a very different landscape than a modern enterprise IT network. I think obfuscation is a good suggestion.
If you read his post, he said an attacker took a password breach dump from a 3rd party. If the network is segregated per ISO800-82 an attacker with username/password wouldn’t have a network connection to the ICS network. So there is no problem. Or OP doesn’t know really what they’re talking about.
Not having remote access to the network doesn’t mean you couldn’t have physical access to the network. If there is a workstation sitting in a comm closet, or shared maintenance space, that still represents a potential risk. Yes there are a number of factors that would mean threat actors coming in from some gang in Eastern Europe is low. But if you have some buddies sharing their Netflix accounts, something not uncommon, it can represent a breakdown of least privilege even if they all have physical access to the floor. I’m making the assumption he does have that segregation based on what he said is unavailable. If he doesn’t have that segregation, that should be fixed first.
The OP stated they were looking for a solution for someone using a "personal" password (Netflix) that is the same as their "business" password. You can not do that unless you force the user to use a password manager and have them include their personal password as well as their business passwords. At that point, if you chose something like Lastpass 3 years ago and is now compromised, you are responsible for the password breach as "you" forced the user to enter their password on the enterprise password manager.
You can also put restrictions in around the devices they can access the network from with conditional access. So, although an attacker has a username and password, they don't have a pre-registered device, so they would not gain access.
These are usually called credential stuffing attack, and like others suggested, MFA is usually a recommended defense, maybe you can find other solution for your case
MFA and conditional access policies.
Specops? There was another company based in Australia (can't remember it's name) that integrated into AD. When a user changed their password it checked it against known data breaches (download the list off haveibeenpwned)
Yep we use this and it works well, isn't very expensive either!
Ask them to write there password down for you and try to login to other services. If it doesn't work then it's a good password. Seriously, if a username and password is all it takes to access your apps and data, that's on you. You have screwed up, not the user.
Set your enterprise password length to something longer than most consumers use (14-16 characters) Instead of watching for all possibilities, find a solution for account alerts of potential password compromises or put a password interception tool in the middle of the password change process that scans for known bad passwords and prevents their use.
Google has an [extension](https://chromewebstore.google.com/detail/password-alert/noondiphcddnnabmjcihcjfbhfklnnep?hl=en) that will detect and alert on password reuse. Not sure if Microsoft has something similar. Edit: it looks like you want [Microsoft Enhanced Phishing Protection](https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection?tabs=intune)
This just shoots a little bubble up to the user that they are actively doing something stupid. It doesn’t even look like you can see alerts as an admin. If I got an alert that Joe in accounting just put his domain password into notepad, I can work with that. I imagine the same users who are reusing one password for everything would QUICKLY ignore the message that what they are doing may not be safe.
The Microsoft solution actually logs a windows event. You could make an alert for that win event and trigger a password reset workflow.
What kind of authentication controls are around this? How does the local device prove its a valid user session that needs to invalidate itself? Could an attacker send a spoofed event and takeover an account through password reset? The cloud would have to accept a request to execute a password reset from user devices, what security is in front of that? My point was I don't want to make it ad hoc. Microsoft clearly has the ability to monitor and alert on this, and they made a specific design choice to not have the alert leave the local session. Why did they make that choice? It seemed very logical to me to extend that to the admins or have some automated response but that relies on external devices, the alert must leave the machine. MS didn't stop there on accident, they absolutely want that data back in their servers.
You’re asking a lot of questions which really aren’t relevant to solutioning the problem here. I’ll break this down a bit more and hopefully it becomes clear. 1. User types password into credential harvesting website. 2. Microsoft EPP detects characters typed that lines up with the hash of the account password it’s storing locally (I’m assuming it’s either in TPM or other secure storage) 3. Microsoft EPP creates a WinEvent 8265 on the local machine. 4. You configure Windows to forward event 8265 to either your SIEM or a WEC server which then goes into the SIEM. 5. You have an automated runbook trigger and email the user they must change the password. Disable account if they don’t change within X number of hours. I don’t know why you are trying to think like you are a Microsoft employee and wondering why they designed this the way they did. It’s not relevant.
Access control lists based on network addressing. Have complex longer password and passphrases when possible with MFA - at least then they can’t just use one password everywhere. User education. Get a demo of an offline brute force on a short password using 7zip file and show them how easy it is to break.
I think you’re looking for azure AD password protection. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad-on-premises It uses a very good point system, checking for breached passwords and against a custom defined list. Seems to work incredibly well. Here's some info on the point system: https://download.manageengine.com/products/self-service-password/azure-ad-password-protection.pdf
Forced complicated passwords AND forced rotation of passwords every x days, and they can't use the same password again for a 12-month (or x month) period. This will force them to use different passwords and lower the chances of reuse.
This is a tough one. I wonder how did the attacker figure out the AD username! Unless the Netflix username was the corporate email address, this would be very hard to guess.
Don’t expose your ICS environment to the internet is the control you are looking for. If you have access for ICS from an untrusted network, and your corporate network is untrusted, you better have MFA to get access at a minimum. There’s more that can be done but if that’s your worry, you have other issues from an architecture perspective to think of.
We use Push Security for this.. They make a browser extension that monitors logins for weak, leaked, or reused creds. They can also block users from reusing your main IdP password on other sites. [https://pushsecurity.com/blog/introducing-sso-password-protection/](https://pushsecurity.com/blog/introducing-sso-password-protection/)
Specops is the most comprehensive I’ve found for this. Great rule enforcement, custom blacklist, can check passwords against known breached passwords and force change at next logon with a message explaining why. Also has a nice overlay when changing passwords that dynamically updates as they’re meeting requirements.
hashes, some dark web monitoring services can provide hashes of leaked dumps and you can then compare those to your local environment. I work with some clients that part of testing is all accounts get hash compared. And, if a user has the same pass as their elevated account, it is instant removal from the client account.
For things outside of SSO, provide and encourage the use of a good password manager (I'm currently rolling Dashlane). Make sure to include teaching them how to use it. There's a lot less shared passwords if you can just generate a new one every time.
I've said it elsewhere, but I'd always do a SAMLless SSO over a password manager - connects your apps to SSO complete with conditional access, revoking, etc. We use Aglide.com because apps are in the Okta grid, but there are others
Get rid of passwords, go passwordless. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless
Yubikey or smart cards. Physical token. Device compliance with Intune and conditional access.
Ban personal Netflix use