Implement Password Strength Meter API

[aeneasr]

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

The API should return a password strength ranging from 0.0 (weak) to 1.0 (strong) to support frontends with displaying a password-strength meter.

[Firstyear]

I'd recommend you look at zxcvbn as it also provides good feedback on how users can improve their passwords, and has js, go, rs, py and other implementations for client and server side validation.

[aeneasr]

Thanks! That looks pretty good. We're already checking against HIBP to find leaked passwords, but I think preventing certain patterns (aaa) is a good idea also.

[aeneasr]

https://github.com/nbutton23/zxcvbn-go

[yindia]

Anyone working on this ?

[aeneasr]

Not right now - we can discuss ideas tomorrow :)

…

On 11. Dec 2019, at 19:04, Yuvraj ***@***.***> wrote:  Anyone working on this ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[yindia]

@aeneasr can we write it as package in ory/x so that hydra can also use this route like health route

[aeneasr]

Hydra doesn't need this :)

[aeneasr]

I'm closing this because we went another route with password policies. We're using things like Levensthein Distance and HIBP API to find if a password is uncompromised and hard to guess.

[juliandroid]

Is it possible ory.sh/kratos/docs/concepts/security/ to be updated, since it references this ticket here?

[aeneasr]

Right, we could probably offer a binary API that runs the password validation against e.g. { "password": ... } and returns either ok or the error. It wouldn't be a password meter in the classical sense though.

[aeneasr]

I am closing this issue as it has not received any engagement from the community or maintainers in a long time. That does not imply that the issue has no merit. If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you to anyone who participated in the issue! 🙏✌️