Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.0.b4
-
Fix Version/s: 4.3.0-b1
-
Component/s: Client Interface, Staff Interface
-
Labels:None
Description
To setup password-autogeneration, add a set of data attributes to a clickable element, which will open a modal and allow you to generate a password.
The clickable element must have the class name generate-password to automatically be set as a password-generating modal.
The following data attributes must be set on the generate-password-class element:
- data-base-url The base URL of the Blesta installation. This is generally the value of $this->base_uri in php
- data-for-class The name of a CSS class to set the generated password to. HTML elements of this class will be set the password
- data-length The length of the password to generate (e.g. 10)
- data-options A string-representation of JSON data representing characters to include in the password generator. This must be formatted as described in unicode-passgen.
- The below example will include all latin alpha characters lower-case and upper-case from A to Z, but exclude the lower and upper-case letter 'i'.
- {"include": [{"chars": [["A", "Z"], ["a", "z"]]}], "exclude": [{"chars": [["i"], ["I"]]}]}
The following data attributes are optional:
- data-modal-title This is the title to set for the modal. By default, it will use the text of the generate-password element
- (Admin UI only) data-modal-close This is the name to set as the close button language, e.g. 'Close'
Password fields are used throughout the system, (in core, modules, etc.) many of which need 2 fields (one for the password, one for confirmation).
We would like to include a simple Blesta core-javascript function for generating a modal, allowing a password to be generated and auto-populate the password fields. It will show the user the plaintext password so they can copy it (like cPanel).
A simple "data-generate-password='unique_field'" attribute to the input field(s) would auto-set this modal to the form next to the field. I imagine the attribute should contain a unique value per SET of fields to which the password should apply.
e.g.
if we have password and confirm_password fields, they should both have the same attribute value so that we only display the "generate password" link next to the first field, instead of both, and both will still be updated when a password is generated.
Issue Links
Activity
WHM/cPanel's password generator is a good example.
Paul Phillips
added a comment - WHM/cPanel's password generator is a good example. FYI, these libraries are interesting
https://github.com/brendanashworth/generate-password/
https://github.com/timseverien/passy/
We probably have to roll our own generator since I'm unable to find one that allows a min/max character length to be set.
I think it should support options for
- digits 0-9
- lowercase characters a-z
- uppercase charactes A-Z
- symbols, e.g.: !@#$%^&*()'",<.>;:/?=+|-_]}[{
- strict digits: set the minimum number of digits that must be in the password
- strict lowercase alpha: set the minimum number of chars that must be in the password
- strict uppercase alpha: set the minimum number of digits that must be in the password
- strict symbols: set the minimum number of digits that must be in the password
- exclude: specify specific characters to exclude from the above alpha/digits/symbols
- custom: specify a custom list of all characters to allow
Unless 'custom' is provided, the other fields should all work together. This also means that if someone tries to require uppercase characters A-Z but also excludes all uppercase characters A-Z then this will NOT be able to generate a password since it is impossible to meet the requirements under those constraints.
Tyson Phillips (Inactive)
added a comment - FYI, these libraries are interesting
https://github.com/brendanashworth/generate-password/
https://github.com/timseverien/passy/
We probably have to roll our own generator since I'm unable to find one that allows a min/max character length to be set.
I think it should support options for
digits 0-9
lowercase characters a-z
uppercase charactes A-Z
symbols, e.g.: !@#$%^&*()'",<.>;:/?=+|-_]}[{
strict digits: set the minimum number of digits that must be in the password
strict lowercase alpha: set the minimum number of chars that must be in the password
strict uppercase alpha: set the minimum number of digits that must be in the password
strict symbols: set the minimum number of digits that must be in the password
exclude: specify specific characters to exclude from the above alpha/digits/symbols
custom: specify a custom list of all characters to allow
Unless 'custom' is provided, the other fields should all work together. This also means that if someone tries to require uppercase characters A-Z but also excludes all uppercase characters A-Z then this will NOT be able to generate a password since it is impossible to meet the requirements under those constraints. I like passy because it values length over different types of characters and I could see us using this anyplace a client enters a password, like when registering their account on the order forms, to give an indicator of strength. What are your thoughts on zxcvbn?
generate-password seems good. Is the main issue that the length is static? Do we want to generate passwords of a random length with min/max length? I've never seen a password generator that didn't generate the same length passwords, or at most, allowed the user to define the length.
Paul Phillips
added a comment - I like passy because it values length over different types of characters and I could see us using this anyplace a client enters a password, like when registering their account on the order forms, to give an indicator of strength. What are your thoughts on zxcvbn?
generate-password seems good. Is the main issue that the length is static? Do we want to generate passwords of a random length with min/max length? I've never seen a password generator that didn't generate the same length passwords, or at most, allowed the user to define the length. We could force a consistent fixed length (although we currently don't in several places) and use one of the libraries, but we would have to at least add data-attribute support to override the values generated from them (if possible).
The generate-password library is nice because it has some good options, but it's "strict" option is to include at least one character from each enabled character type, which is good, but not necessarily flexible enough (maybe something requires at least 2 digits?). Since this password generator will be used pretty much everywhere in Blesta, including for all extensions that use passwords, having more flexibility will be useful since we need to support and generate a password that meets the requirements of all third-party extensions. That's why the options I listed above have more general support for varying password requirements by having flexible strict options and also excluding/including specific characters.
As for the strength indicator, like zxcvbn--those are nice to give a visual representation of a password strength, but at least with zxcvbn, it doesn't generate passwords. So that could be something that is added in the future to give that perspective.
Also, the password generator for Blesta will presumably be setup to generate a password optimal for the location it will be used (e.g. SolusVM). However, a password strength indicator may still find the generated password to be inadequate, although it matches the requirements perfectly. For example, if some extension requires at most 8 characters in a password length, and we generate an 8-character password, that is the best-length password that could be created, but a password strength indicator would say that's obviously terrible. If someone sees that the strength is terrible they may change it to 9 characters and submit it, only to retrieve an error from the extension that the length has been exceeded.
Tyson Phillips (Inactive)
added a comment - - edited We could force a consistent fixed length (although we currently don't in several places) and use one of the libraries, but we would have to at least add data-attribute support to override the values generated from them (if possible).
The generate-password library is nice because it has some good options, but it's "strict" option is to include at least one character from each enabled character type, which is good, but not necessarily flexible enough (maybe something requires at least 2 digits?). Since this password generator will be used pretty much everywhere in Blesta, including for all extensions that use passwords, having more flexibility will be useful since we need to support and generate a password that meets the requirements of all third-party extensions. That's why the options I listed above have more general support for varying password requirements by having flexible strict options and also excluding/including specific characters.
As for the strength indicator, like zxcvbn--those are nice to give a visual representation of a password strength, but at least with zxcvbn, it doesn't generate passwords. So that could be something that is added in the future to give that perspective.
Also, the password generator for Blesta will presumably be setup to generate a password optimal for the location it will be used (e.g. SolusVM). However, a password strength indicator may still find the generated password to be inadequate, although it matches the requirements perfectly. For example, if some extension requires at most 8 characters in a password length, and we generate an 8-character password, that is the best-length password that could be created, but a password strength indicator would say that's obviously terrible. If someone sees that the strength is terrible they may change it to 9 characters and submit it, only to retrieve an error from the extension that the length has been exceeded. I was thinking a UTF-8/Unicode support would be great. Instead of using the options I mentioned in my previous comment, we could just accept unicode ranges,
e.g. [u0000-u00FF, u0100-u0200]
and generate a list of characters from the given unicode ranges.
Useful things to consider:
https://mathiasbynens.be/notes/javascript-unicode (good info on unicode issues in JS)
https://github.com/mathiasbynens/regenerate (i.e. to generate a string of all characters from the range in order to build a new random string)
https://github.com/mathiasbynens/he (i.e. displaying unicode characters correctly in HTML)
However, developing that unicode password generator may take too long, so this library could suffice for latin character support in the interim:
https://www.npmjs.com/package/randomatic (No browser support)
Tyson Phillips (Inactive)
added a comment - - edited I was thinking a UTF-8/Unicode support would be great. Instead of using the options I mentioned in my previous comment, we could just accept unicode ranges,
e.g. [u0000-u00FF, u0100-u0200]
and generate a list of characters from the given unicode ranges.
Useful things to consider:
https://mathiasbynens.be/notes/javascript-unicode (good info on unicode issues in JS)
https://github.com/mathiasbynens/regenerate (i.e. to generate a string of all characters from the range in order to build a new random string)
https://github.com/mathiasbynens/he (i.e. displaying unicode characters correctly in HTML)
However, developing that unicode password generator may take too long, so this library could suffice for latin character support in the interim:
https://www.npmjs.com/package/randomatic (No browser support) 
Password strength estimator see https://github.com/dropbox/zxcvbn
Possibly could be adopted to generate passwords?
Question: How well does this work with non-english languages?