Skip to content
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

No Password Complexity Checks #526

Open
Asterius27 opened this issue Jul 10, 2024 · 1 comment
Open

No Password Complexity Checks #526

Asterius27 opened this issue Jul 10, 2024 · 1 comment

Comments

@Asterius27
Copy link

Asterius27 commented Jul 10, 2024

Hello shopcube developers,

We are a cybersecurity research group from the CISPA Helmholtz Center for Information Security and Ca’ Foscari University of Venice. We recently conducted an analysis of the session management in web applications on GitHub as part of our research. We have discovered a security vulnerability in your code that we believe requires your attention.

Vulnerability Description:

With our analysis, we have identified that your application is not performing any password complexity checks upon user registration, it only checks that the password length is between 6 and 25 characters. This would allow users to set very weak passwords such as “123456”, which, in turn, would expose them to the risk of getting their accounts stolen. This is because weak passwords, in addition to being vulnerable to brute-force attacks, can also be easily guessed.

Recommendation for Mitigation:

We recommend adding the regexp validator (https://wtforms.readthedocs.io/en/3.1.x/validators/#wtforms.validators.Regexp), available in WTForms and Flask-WTF, in order to perform password complexity checks. By adding this validator, passwords will have to match a certain regular expression, otherwise they will be rejected. A simple regexp that could be used is the following: “^(?=.[A-Z])(?=.[a-z])(?=.\d)(?=.[@$!%?&])[A-Za-z\d@$!%?&]$”. This regexp checks for the presence of an uppercase, lowercase, digit and special character.

We hope this notification helps improve your security.

In addition to addressing this issue, we are interested in understanding how this vulnerability was introduced in the code or why it has remained unchanged. This information can provide valuable insights into common security pitfalls and help us all improve security practices in the future. Could you share any background on this aspect? We would greatly appreciate your input on this matter. Thank you!

Should you have further questions or comments on this, feel free to answer this thread.

Kind regards,
Simone

@Abdur-rahmaanJ
Copy link
Owner

How was it introduced?

  • Used default from another package, also partly because it was a small project at first
  • Why remained unchanged? Did not focus on it till you bring this out today

Thanks a lot!

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

2 participants