For now, genpass uses an internal algorithm to generate a password. I prefer to use a different algorithm. Here is a patch which allows third-party modules to implement a genpass hook. For example, mymodule could implement a function called mymodule_genpass_genpass(), which would return a password. If any such module is present, its generated password will override the internal algorithm, provided the password contains at least one character and is a string. If more than one module implements the hook, then only one actually gets to create the password.

I am including also a sample third-party module called pronpasswordgen which implements the hook so you see how it works. pronpasswordgen tries to create a pronounceable password using an algorithm by Andreas Gohr. If you enable pronpasswordgen, it will override the default algorithm. If you enable pronpasswordgen_ui, you can visit the pronpasswordgen_ui path on your site and it will show you that everything is actually working without you having to create new user accounts.

I hope this can be of use to certain users. Cheers,

Albert.

CommentFileSizeAuthor
#3 genpass.643536.3.patch4.69 KBalberto56
#3 pronpasswordgen.643536.3.zip6.27 KBalberto56
pronpasswordgen.zip6.24 KBalberto56
genpass_override.patch2.79 KBalberto56

Comments

japanitrat’s picture

japanitrat commented

Hi Albert,

thanks for the input you are providing here. Always nice to smell some fresh air.

Regarding your code: Why not stick with the original name of the password-function for the hook (i.e. hook_genpass_password), the suggested one is kinda confusing. Secondly: currently the password gets delivered in the $op-parameter though it should be delivered in the $data-parameter (being consistent to the API).

Regarding the idea: Where are administrators able to choose which algorithm to use in case there is more than one implementation available? As pointed out in the comments, the first hit is processed, so this comes down to module-deltas, am I right? If this can be solved nicely, we could even call the hook "hook_password", which would also enable the default Drupal-implementation (user_password) as possible implementation.

Interesting stuff indeed ..

alberto56’s picture

alberto56 commented

japanitrat,

thanks for the feedback; you raised a lot of interesting points. This is my first attempt at submitting a patch that actually implements a feature, and I'm glad to have some constructive criticism to work from. Your ideas are all sensible and I am anxious to play around with them when I have some spare time (maybe this weekend)!

Albert.

alberto56’s picture

alberto56 commented
StatusFileSize
new pronpasswordgen.643536.3.zip6.27 KB
new genpass.643536.3.patch4.69 KB

Here is an updated version of the patch and the sample 'pronpasswordgen' module which implements the alternative algorithm.

Some improvements:
- I am calling hook_password as suggested.
- I am allowing admins to select the preferred algorithm in the User Settings form.
- I am no longer passing anything to the hook's implementation, to keep things simple.

Cheers,

A.

japanitrat’s picture

japanitrat commented

Awesome! It seems half the code and twice the power, to me at least. Neat stuff you did there.

I added the changes in genpass.module to the development release (which I also enabled now, should be updated tonight). I also fixed a missing generate statement in the admin-registration form for the sake of completeness.

Now to the pronpassword module. I am not quite sure, where to add this one. It could be placed in a subfolder like "genpass/algorithms/pronpassword" or standalone as a new project, what do you think? I am curious about the additional ui module though, since it seems a bit oversized (although I am a big fan of encapsulation, don't get me wrong here). I mean, if a user enables pronpassword, he's most likely about to enable the ui-module, too. I just don't see no need for another module if the functionality (which is clearly in the scope of pronpassword only) can be implemented in the very same module.

There might be a solution where algorithms can define their own option-pages which can be accessed from the radio-list in the user-settings without having to modify an additional ui module.

At this point the default algorithm and options (like length and entropy) of genpass itself should also be outsourced like user_password or pronpassword, since its just a different algorithm. So we would have two starting algorithm-modules, genpass/algorithms/enhancedpassword (for the enhanced drupal default) and genpass/algorithms/pronpassword (for the pronounced password generator). Question is how to allow every algorithm adding its own option-pages to the radio-list.

alberto56’s picture

alberto56 commented

Hi, thanks for your comments!

Regarding the pronpasswordgen module, it was really meant as a sample module to show that the idea works (proof of concept). I wouldn't add it to genpass for that reason. And, yes, I tend to be a bit extreme about separating the UI from the API, but in this case it might be overkill! Maybe the UI is not even necessary here; I included it only to prove that things work. Of course, including it in your module would provide a starting point for coders wanting to implement their own algorithms.

Having each algorithm define its options is a good idea. Perhaps we could have another hook which, if implemented, would send back a form snippet if $op='get', and if $op='set', would set the options for the algorithm.

Cheers,

Albert.

SeanA’s picture

SeanA commented
Status: Needs review » Fixed

Marking as fixed. http://drupal.org/cvs?commit=296340

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.