Add dynamic data/interactions to Password component

[iandunn]

Fixes #27

[xknown]

Out of curiosity, why are doing this on the client side? Do we have the same checks on the backend that block weak or compromised passwords?

[iandunn]

Building a custom UI was one of the requirements of the project, since the design of the wp-admin UI in the upstream plugin isn't modern enough.

I did initially use the generate-password AJAX endpoint to generate the password, but we decided to switch to doing it in the browser for performance/UX.

The client does check check the strength, and blocks saving when it's too weak. It's checked with zxcvbn, and we
require a higher entropy score for folks with elevated privileges. zxcvbn is somewhat outdated, but it's what Core still uses. If you feel like that's not good enough, I'd be open to swapping in a different one.

The REST endpoint doesn't check the strength when saving, so somebody could intentionally set a weak password if they really wanted to. But, we do have some backend code in a separate plugin that monitors for weak/compromised passwords, and would force them to reset it.

[xknown]

The client does check check the strength, and blocks saving when it's too weak. It's checked with zxcvbn, and we
require a higher entropy score for folks with elevated privileges. zxcvbn is somewhat outdated, but it's what Core still uses. If you feel like that's not good enough, I'd be open to swapping in a different one.

The REST endpoint doesn't check the strength when saving, so somebody could intentionally set a weak password if they really wanted to. But, we do have some backend code in a separate plugin that monitors for weak/compromised passwords, and would force them to reset it.

While I understand the motivations of doing this only client side, I think it'd be good to also enforce this on the backend, especially if we have already existing code to check for compromised/weak passwords -- it wouldn't be a good UX to set a password via this endpoint, and then later be blocked because it was considered weak or compromised somewhere else. Also, doing this only client side will most likely be reported in our bounty program :)

[iandunn]

👍🏻 , I added backend validation to the endpoint in r19805-dotorg.

[dd32]

While I understand the motivations of doing this only client side, I think it'd be good to also enforce this on the backend,

I added backend validation to the endpoint in r19805-dotorg.

It's worth noting that WordPress core / wp-admin doesn't do this, you can set any password as all the validation is client-side. As a result, we'll have to disable the admin UIs, I've opened #37 to track that.