2

We're trying to build a solution where we have a requirement to check password compliance of a user with respect to all the systems that he has to.

For example, if system 1 mandates that password should have 4 alphabets and system 2 has a requirement of 5 alphabets, if the user happens to have access to both systems 1 & 2 , we need to make sure that his current password has 5 alphabets. We have similar password composition requirements like number of special characters, number of digits, min length etc.

Systems are at liberty to change password composition at any time so when the user logs in to any of the systems that he has access to, we need to calculate effective password policy (basically a union of all individual system policies) and prompt the user to change his password if it's not compliant.

We want to do this without having to store/ remember the user's password in plain text anywhere and in a secure fashion.

Our current option is,

Get password composition (just the no of digits, alphabets, special characters, length) during login and pass that information to a service that can tell us whether it's compliant or not.

Is there any better way to do this ? Appreciate any help on this.

Note: If you think that this should be asked in a different site in stack exchange, please let me know.

Improve this question
2
  • What are you trying to solve? are you trying to implement some sort of single sign on?
    – RubberChickenLeader
    Commented Nov 3, 2017 at 14:28
  • We support SSO but you can say it's more of an identity provider which gives flexibility for relying parties to configure their password policies. Think of it as a Google account which provides access to multiple Google services like Gmail, YouTube etc but unfortunately we had to support password policies separately for both Gmail and YouTube and prompt them to update their password if Gmail/YouTube changes password policy, derive a news effective policy which is a union of both.
    – Arkantos
    Commented Nov 3, 2017 at 16:58

1 Answer 1

Reset to default
8

Those requirements are a nightmare for developers and users. Your best option would be to find the person who decided that the system would work like that, and fire him before he causes your users to leave for a better alternative (or, if the users are your employees, leave for a better employer.)

You are seeing a technical side of the problem, which might be fun. Take a set of constraints, combine them. But there is the user experience side you are missing:

  • How do you explain what is wrong with a password when you ask the user to change it?

  • How does it feel for the user to know that you know something about his password, such as the number of capital letters? As a user, I don't even care you stored only the count itself; as soon as you tell me that my previous password contains six capital letters and two symbols, you lose all my trust.

  • What does it mean that my password which was compliant yesterday afternoon is not compliant this morning? The only reason I need to change my password is because the system screwed up security-speaking, i.e. it leaked all the passwords and my account could be affected. Showing that you got hacked on regular basis won't get you any trust either.

  • How do you handle contradictory constraints? For instance the system 1 accepts passwords between 8 and 12 characters, while the system 2 requires at least 15 characters.

A better way is to configure the systems to be uniform. Same rules everywhere, and the rules are easy to understand, clear, and don't create insecurity for your users. Security.SE contains a few questions on this subject, starting with this one.

Improve this answer
5
  • 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.
    – Arkantos
    Commented Nov 3, 2017 at 16:59
  • 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.
    – Arkantos
    Commented Nov 3, 2017 at 17:04
  • 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.
    – Arkantos
    Commented Nov 3, 2017 at 17:11
  • 1
    @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.
    – Brian
    Commented Nov 6, 2017 at 19:15
  • @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.
    – Brian
    Commented Nov 6, 2017 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.