Timeline for Password policy compliance design
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2017 at 19:16 | comment | added | Brian | @Arkantos: The alternative approach to being an identity provider is to allow any set of one or more services to select their authentication requirements, and for those shared services to share a provider. It is up to the service-providers to agree with one another on standards, and any providers who cannot work together are out of luck. | |
| Nov 6, 2017 at 19:15 | comment | added | Brian | @Arkantos: The normal approach to being an identity provider is to do 1 of two things: In the standard approach, you pick your own standards, and anyone who doesn't like those standards is out of luck. This is the approach when you are primarily focused on serving users; authentication being treated more as a user service. | |
| Nov 3, 2017 at 17:11 | comment | added | Arkantos | We try to explain our users as much as we can by explicitly stating that password policies of one/more of the systems that he has access to are modified and he needs to update his password if his current password doesn't meet the new requirements. Coming to last point, we don't have contradictory policies. All policies should say min and max length. If system 1 has 8-30 and system 2 has 10-20, the effective policy for a user having access to both systems is 10-30 and if users password is say 12 characters we don't have to ask him to change. Hope that clarifies our requirements. | |
| Nov 3, 2017 at 17:04 | comment | added | Arkantos | I totally agree with your opinion that these kind of password policies are hard on our users as they might need to (not always) change password when they login through a different system. The reason I posted this question is because of point #2. | |
| Nov 3, 2017 at 16:59 | comment | added | Arkantos | Unfortunately these are NIST standards that we need to comply with and us being an identity provider, all of our relying parties should be able to configure their own password policy. | |
| Nov 2, 2017 at 19:24 | history | answered | Arseni Mourzenko | CC BY-SA 3.0 |