Is there a way for me to customize the default password length requirement while using the Password strategy of `ash_authentication`?

Ash Forum Ash Questions / Help
,
1

I’m using a pretty vanilla implementation and seeing:

“length must be greater than or equal to 8”

I’d like that to be 20.

Ideally, I would like to see something like password_length_requirement in the DSL. Is that something the project would welcome as an addition?

I feel like people would want to customize that for different business needs too (so maybe the real solution is a little more customizable than just a single new DSL addition).

https://hexdocs.pm/ash_authentication/AshAuthentication.Strategy.Password.html#module-dsl-documentation

2

You can probably add a min_length constraint on the password field

https://hexdocs.pm/ash/Ash.Type.String.html

3

@adw632 has it right.

The other options are to override the register_with_password action and add your own validations, but probable the best way is to add a custom validation in the global validations block.

For example:

validations do
  validate string_length(:password. min: 20) do
    where action_is(:register_with_password)
  end
end
1 Like
4

I was thinking just an attribute level constraint:

attributes do
  attribute :password, :string do
    constraints [
      max_length: 64,
      min_length: 20,
      allow_empty?: false
    ]
  end
end
5

yeah, that’s what I was thinking but it occurs to me that :password is an argument to those actions and not actually an attribute as we never want to store the plaintext password.

2 Likes
6

Ahhh, yes you’re right it would be an argument as you only store the salted/hashed password.

7

Thanks so much for the suggestion.

I gave this a shot tonight and the logic I observed was that this did not override the built-in validation so when I submitted a small password I got back an error message saying it needed to be 8 and then if I changed it to a 10 character password I would get a new (slightly different Ash.Error.Changes.InvalidArgument saying password needed to be 20.

Going to continue to investigate to see if I can augment the current logic or if a true API addition / PR is needed.

8

yeah that makes sense - we’re racing to apply whichever validation fails first. It make make sense for us to add a default_password_validations? DSL option or something that lets you disable the generated ones.

Should be easy enough to add.

9

Probably some options for password validation would be useful. Password validation policies can be quite varied and often specified by corporate numskulls.

Examples of constraints can include password length, character complexity, dictionary word checks, blacklists, not “similar” to the previous one (or “recent” ones).

I think some escape hatch for specifying a validator would be good to provide full flexibility.

There may be some opportunity to avoid the specific racing/inconsistency problem above of “at least 8” and then “at least 20”, possibly by coalescing/overriding validations of the same type.

1 Like
10

I’d be keen to add this. Can you raise an issue on AA with the relevant details?

11

Thanks. Here is a new issue we can use to start talking:

12

Thanks!