Skip to content

Insecure password blocking sign up flow is annoying #14984

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ammario opened this issue Oct 4, 2024 · 4 comments
Closed

Insecure password blocking sign up flow is annoying #14984

ammario opened this issue Oct 4, 2024 · 4 comments
Assignees

Comments

@ammario
Copy link
Member

ammario commented Oct 4, 2024

So this is quite annoying:

  • We don't give the user clear instructions how the password should come into compliance, instead forcing a trial-and-error flow
  • Makes it hard to quickly set up a Coder deployment for testing
  • The warning only updates on submit... it should update in real time. These entropy checks are not expensive?

Since this is a product directed towards a technical audience I would much prefer we make this entropy check a warning and not block sign up. Deployments with hefty security requirements should use SSO and not built in auth anyways.

Screenshot 2024-10-04 at 1 29 55 PM
@defelmnq
Copy link
Contributor

defelmnq commented Oct 18, 2024

@ammario I'm working on this one currently. Based on your comments and what I checked in the code - I plan to :

  • Remove the entropy validation in the backend (not explicit enough.)
  • Add a condition both frontend and backend side to ensure the password is between 6 and 64 characters - does not matter the pattern.
  • Validation will be done frontend side (so will be easier to iterate on for the users.) but I keep it also backend side just in case obviously.

We can add more rules if we want, but I feel like based on your description it will be enough.

Also, do we want to use this opportunity to change it overall in our password flows , or just for this specific one ?

@ammario
Copy link
Member Author

ammario commented Oct 18, 2024

If I understand it correctly you're removing all entropy checking? I think it's a nice feature on the frontend (when non-blocking) but don't feel strongly we should have it if inconvenient to implement.

Validation will be done frontend side (so will be easier to iterate on for the users.) but I keep it also backend side just in case obviously.
The backend implementation is important for CLI flows. Some of our users build new frontends around Coder too.

An idea is keeping all validation in the backend and implementing a "check" endpoint to avoid issues of behavioral mismatch between FE and BE. The FE can send inputted passwords to the BE with a debounce before the user hits submit.

Also, do we want to use this opportunity to change it overall in our password flows , or just for this specific one ?

And, I do believe we should have a consistent UX and code-paths for every place we accept new passwords.

defelmnq added a commit that referenced this issue Nov 5, 2024
Refers to #14984 

Currently, password validation is done backend side and is not explicit
enough so it can be painful to create first users.
We'd like to make this validation easier - but also duplicate it
frontend side to make it smoother.

Flows involved : 
- First user set password
- New user set password
- Change password

---------

Co-authored-by: BrunoQuaresma <bruno_nonato_quaresma@hotmail.com>
jaaydenh pushed a commit that referenced this issue Nov 5, 2024
Refers to #14984 

Currently, password validation is done backend side and is not explicit
enough so it can be painful to create first users.
We'd like to make this validation easier - but also duplicate it
frontend side to make it smoother.

Flows involved : 
- First user set password
- New user set password
- Change password

---------

Co-authored-by: BrunoQuaresma <bruno_nonato_quaresma@hotmail.com>
@mtojek
Copy link
Member

mtojek commented Nov 6, 2024

@defelmnq Is there anything left here or can we resolve this issue now?

@defelmnq
Copy link
Contributor

defelmnq commented Nov 7, 2024

All good now, resolved with the PR merged for a first iteration.

@defelmnq defelmnq closed this as completed Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants