Password policies: make settings configurable

[radekg]

Is your feature request related to a problem? Please describe.

Not related to an issue.

Describe the solution you'd like

Currently, minimum password length, minIdentifierPasswordDist and maxIdentifierPasswordSubstrThreshold are currently hard coded. I would like to have configuration options to configure these settings using Kratos configuration. Additionally, have an option to maybe specify minimum number of character in certain classes, similar to Keycloak: lowercase, uppercase, special characters.

Describe alternatives you've considered

A hook but I see no option to define custom hooks, for example HTTP based hooks.

Additional context

For services deployed in private networks where the password rules might be distributed from an external source.

[aeneasr]

Password complexity is an anti-pattern, please read: https://www.ory.sh/kratos/docs/concepts/security#passwords

The chosen values are best-practice values. Why do you want to change them?

[wangchucheng]

Vote for configurable password policies.

For intense, kratos now use HIBP api to check the leaking possibilities. Some users may feel umcomfortable when seeing "password has been found in xxxx". They do not know how it works so they may even regard this safer approach as risky. Most apps are not like Google or Apple, most apps lack this "credibility".

Therefore, in some cases, I think it may be a better choice to allow users to customize password policies.

[aeneasr]

That’s not how security works. Users will learn eventually how this works. It protects them. Disabling it does not.

[aeneasr]

You can always adjust the error message in your UI also

[radekg]

Hey, so I've been actually thinking a bit more about my original request. I've mixed up two things there.

1. make the min length, minIdentifierPasswordDist and maxIdentifierPasswordSubstrThreshold configurable
2. allow specifying character classes

Re 1. I'm fine with the defaults. I mean, it would be nice for some use cases to require longer passwords. For example registering API clients.

Re 2. I understand the best practices around passwords and I totally agree on "users should be educated on passwords". Unfortunately, the real world is what it is and businesses have to deal with decision makers who have their own views on what the systems should support. I fear that the lack of being able to explicitly specify what character classes to use may disqualify Kratos in the eyes of some of those decision makers who simply do not get it and refuse authority.

Now, when we consider the minimum password requirement + HIBP integration, it actually does not matter which character groups and at what counts are in use. I know, you know, the guy next to knows that. So, I wonder if there is a middle ground here. If there was a way to implement a pre-validation hook, without the ability to skip already implemented validation, that would allow people to implement a feature like that.

This potentially prevents people from doing other silly stuff like putting some kind of reverse proxies in front just to implement such requirement and potentially screwing up in other ways by actually decreasing security with those layers in between.

[aeneasr]

Yeah, that's a fair point. I think the password distance things should be configurable as they can be too strict or too lose.

Regarding password "complexity" or character classes - one thing we had planned was to actually not send the password in hooks! Because we feel that the password does not belong anywhere else. Think about an accidental log statement on error which drops, for example, the request payload (this actually happened at Facebook!) or similar problems.

Another possibility would be to use JSON Schema for this? It has all the stuff in there with min/max/regex/format/...

[ethanchangbd]

Regarding this, where can I get the password policy structure or requirements.

[zepatrik]

This is the current password validator implementation: https://github.com/ory/kratos/blob/4b9da3c9d98d40f7b71a56c51543fc115974630d/selfservice/strategy/password/validator.go

[radekg]

Hey @aeneasr,

Another possibility would be to use JSON Schema for this? It has all the stuff in there with ...

That sounds like a reasonable idea. This should be pretty easy to add. I guess the schema (or the link to the schema, rather) could be configurable via new selfservice.methods.password.config.... property.

What would be really neat is to also have an API endpoint to fetch that schema so it could be used to drive a user interface. Similar to what Keycloak offers. On the second thought, being able to pass my own schema from a URL, it's possible to load that schema back in the front end app and do it without an endpoint. An endpoint would make it easier to integrate Kratos but technically, endpoint isn't required.

If the direction is okay for you, I can pick it up.

[aeneasr]

Thinking about this again - JSON Schema is really something to verify JSON, not really for singular fields - the following configs would be for example non-sensical:

type: object

type: array

type: string
format: email

Only this really makes sense:

type: string
pattern: ...

So not sure...

[g13013]

@aeneasr Kratos should allow to disable password policies all together or tweak the settings for whatever fits the application needs ! even though Kratos wants to enforce best practice regarding security, we cannot ask providers to force there existing users into bizarre workflows to import their credentials.

We have had hard times implementing fairly complex workflows to seamlessly import existing accounts without the user noticing the change but we are stuck because legacy passwords are not accepted when the users type their weak existing passwords, we don't want to ask the users to change their password when they try to login as they normally do.

As we might ask users to provide better passwords in the future, this would cause a problem if we want to support both strategies at the same time, but this is another story, solutions might exist.

I think that it's up to the provider to chose whatever policy it want to impose. Now it feels like removing sudo from linux for administrators.

but for now, please consider making password policies totaly configurable.

[drishi]

+1 to making password settings configurable. Different applications have different security requirements, and it'd be great if the developer can choose which policy is most appropriate for their use case.

[g13013]

any updates on this ?

[IgorGov]

+1 to making password settings configurable. Different applications have different security requirements, and it'd be great if the developer can choose which policy is most appropriate for their use case.

+1

[Sytten]

This should probably not be closed. Even if in a "better" world the password should have complexity, regulations and user expectations must also be taken into account. This means having settings to specify the number of uppercase, number and symbols.

[bcordobaq]

Are you considering extending the password settings to support additional checks like @Sytten commented and/or adding other mechanisms like password history? I'm aware that you indicated those cases like anti-patterns, but some customers still require them as a check...

[radekg]

The problem with how things are right now is the following:

• One can either use the HIBP check or disable it.
• In air-gapped environments, it may be e difficult to get an egress policy towards HIBP API. Hence my original pull request from a couple of years ago added a customizable HIBP API endpoint.
• HIBP check can be disabled. However, when disabled, nothing prevents a user from submitting a weak password.
  • Because it is impossible to send the password via webhook, there's zero protection from submitting a weak password.

@aeneasr I get your point re not sending passwords via webhooks, although I don't like that level of hand-holding from your side towards the users, no offense.

Thinking further: disabling the HIBP check, tweaking existing parameters, and providing a custom trait would be a hacky way to implement a password replacement via hooks. Bit creative but could work… If I were to go about it today, I'd do the following:

• Do not render the default Kratos password trait field to the user.
• Present my own password control backed by my own custom trait.
• Disable the HIBP check, and present a random password to Kratos from the frontend application, transparent for the user.
• Validate my custom password trait against the rules I want.
• Post-process the credential afterward, and replace the random password with the one provided by the user AFTER the account is created. This may require offloading my own password to something like sidekiq... use the same hasher that Kratos would use while doing so to make the regular login work.

Pros: win-win—cons: none.

I already made all the effort to run everything with TLS, configure cookies, domains, provide secrets from k8s secrets, and whatnot, put network policies in place, have gatekeeper guarding me all around so if I accidentally leak someone's passwords in logs, let me deal with the fallout. Because you can't stop me, albeit you do make me work for it. Again, no offense. Just thinking out loud.