-
Notifications
You must be signed in to change notification settings - Fork 638
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
Update password policy to allow special characters #297
Comments
Original comment by Stavros Korokithakis (Bitbucket: Stavros, GitHub: Stavros): The password policy is generally weak. Forcing people to have special a certain type of character in their password just makes them have passwords they will forget. Please remove the restrictions altogether and let people have whatever kind of password they want. I have a very long passphrase that is multiple words, and this fails ESPurna's check, so I set my password to something like Password1, which passes. Clearly, my passphrase is much more secure than Password1, but I can't use it because of the security theater. |
Password policy is not the weakest part of the security. Mind that unless you compile it with SSL support all passwords are visible to any sniffing the communications. The password check is just a minimal security that would work in 99% of the cases (except when you have a hacker around). |
Original comment by Stavros Korokithakis (Bitbucket: Stavros, GitHub: Stavros): The point is that it's unnecessarily restrictive. The original reporter can't use their password that contains special characters (and I hit that bug too), and I couldn't use a more secure passphrase, I instead had to use a very unsafe password that I can remember. Please remove the restrictions, maybe just require a length over 4 or so. There's no reason to restrict the user like that when the password can be trivially sniffed anyway. |
Original comment by Stavros Korokithakis (Bitbucket: Stavros, GitHub: Stavros): Also, for example, the password "daaVaraghohheszd" is very secure, and it was what my password generator generated, but it fails your requirements because it happened to not include a number that time. These password policies just make users choose less secure passwords that they then forget or write down on a post-it and stick on the device anyway. |
Original comment by Marco de Gier (Bitbucket: DiGierre, GitHub: Unknown): I agree with Stavros. This is not about passwords itself (there's much to be said about them as well as using it over http/unsecured links) but the point is that you should not unnecessarily restrict it. I am also used to use particular special characters in all my passwords and for Espurna I now have to remember something outside of my personal policy which causes the need for me to write them down as then I cannot remember them. And it is also very easy to change, I see it is just a regex in js. |
@DiGierre @Stavros There's one thing I'm not sure about this issue: you both have a personal password policy that doesn't fit with the policy I set in ESPurna. But most of the people does not have a password policy, removing the checks will result in "12345678" and "password" used as passwords. I agree that more special characters could be used but I don't think it helps allowing shorter passwords or simple words. |
Would this expression make more sense?
Check it here: https://regex101.com/r/dRWUoW/4 |
The change has been released with 1.10.1 |
Original comment by Marco de Gier (Bitbucket: DiGierre, GitHub: Unknown): Hi Xose, |
Removing milestone: 1.10.1 (automated comment) |
Originally reported by: Marco de Gier (Bitbucket: DiGierre, GitHub: Unknown)
The password policy should allow for special characters such as ~!@#$%^&*()<>,./?;:{}[]|
This will make it more secure..
The text was updated successfully, but these errors were encountered: