You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
Here are some documents that Randy Wilson shared on the list - though they state for “Hashpassword: we have not yet found a quicker way to do this than to send the excel file to Bob Jolliffe or Knut Staring (HISP). There is a special algorithm they use to create the MD5 hash password, combining the username and the assigned text password.” Unfortunately I don’t remember exactly how I used to do it…would be good if you share a how to when you figure it out…
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
I think Bob is the best source for this. I have some R scripts but the generated password is not always correct due to peculiar methods which spring uses to encrypt the passwords which elude me.
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
Ken the algorithm is contained in the attached Password.java file (its based on what I figured out from the spring source code). This little java program takes the username and password as parameters and outputs the username,password and hash as recognised by dhis2.
So if you have for example a csv file containing many, many users, then you can incorporate a script along the lines of the attached genpass.tcl to generate the hash codes in bulk. Or just expand the java program to read the csv file and possibly even write into postrgres table. (Personally I prefer to do do things a little bit at a time and script through psql). Anyway thats up to you … the algorithm is here.
There are some security considerations. The hash algorithm itself is not great, but you are stuck with emulating what happens inside dhis2 so no point tinkering with that (MD5 must seem like plaintext to the NSA nowadays). A more important consideration is how to generate the 45000 passwords. I have used the makepasswd program to generate fairly cryptic random passwords (also in a script) but users didn’t like them, naturally. Randy initially assigned them things like password1, password2, password3 etc which is also not ideal.
I wonder is the self registration feature an option for you? Not that users necessarily pick good passwords anyway
I think Bob is the best source for this. I have some R scripts but the generated password is not always correct due to peculiar methods which spring uses to encrypt the passwords which elude me.
Here are some documents that Randy Wilson shared on the list - though they state for “Hashpassword: we have not yet found a quicker way to do this than to send the excel file to Bob Jolliffe or Knut Staring (HISP). There is a special algorithm they use to create the MD5 hash password, combining the username and the assigned text password.” Unfortunately I don’t remember exactly how I used to do it…would be good if you share a how to when you figure it out…
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
Not really fond of registrating users with queries.
I think it will effect the reporting rates in a bad way.
I think registrating users should be done through the DHIS2 interface while giving instructions on how to use the reporting system and involving the right people.
For now I am trying to set up a test environment that will show if DHIS2 is supporting a set of requirements and try to document the steps needed for the system to meet those requirements.
Attached is a draft of the requirements and a simple stand-alone .jar file for testing purposes. encode_password.jar
Ken the algorithm is contained in the attached Password.java file (its based on what I figured out from the spring source code). This little java program takes the username and password as parameters and outputs the username,password and hash as recognised by dhis2.
So if you have for example a csv file containing many, many users, then you can incorporate a script along the lines of the attached genpass.tcl to generate the hash codes in bulk. Or just expand the java program to read the csv file and possibly even write into postrgres table. (Personally I prefer to do do things a little bit at a time and script through psql). Anyway thats up to you … the algorithm is here.
There are some security considerations. The hash algorithm itself is not great, but you are stuck with emulating what happens inside dhis2 so no point tinkering with that (MD5 must seem like plaintext to the NSA nowadays). A more important consideration is how to generate the 45000 passwords. I have used the makepasswd program to generate fairly cryptic random passwords (also in a script) but users didn’t like them, naturally. Randy initially assigned them things like password1, password2, password3 etc which is also not ideal.
I wonder is the self registration feature an option for you? Not that users necessarily pick good passwords anyway
I think Bob is the best source for this. I have some R scripts but the generated password is not always correct due to peculiar methods which spring uses to encrypt the passwords which elude me.
Here are some documents that Randy Wilson shared on the list - though they state for “Hashpassword: we have not yet found a quicker way to do this than to send the excel file to Bob Jolliffe or Knut Staring (HISP). There is a special algorithm they use to create the MD5 hash password, combining the username and the assigned text password.” Unfortunately I don’t remember exactly how I used to do it…would be good if you share a how to when you figure it out…
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.
Have you read one of my mail in previous discussion. I used this approach to generate 2000 users automatically with passwords, roles, and assign them to appropriate orgunit where the users belong to
In case you need to expedite creation of thousands of users and passwords the following classes might help. In essence, all of user creation steps can be done by sql. However, password hash is a bit tricky in dhis2 when it depends on Spring Security.
After having a list of username and password pairs you can use sql to fill in users and userinfo tables, plus other germane tables for assigning orgunit and roles.
Not really fond of registrating users with queries.
I think it will effect the reporting rates in a bad way.
I think registrating users should be done through the DHIS2 interface while giving instructions on how to use the reporting system and involving the right people.
For now I am trying to set up a test environment that will show if DHIS2 is supporting a set of requirements and try to document the steps needed for the system to meet those requirements.
Attached is a draft of the requirements and a simple stand-alone .jar file for testing purposes. encode_password.jar
Ken the algorithm is contained in the attached Password.java file (its based on what I figured out from the spring source code). This little java program takes the username and password as parameters and outputs the username,password and hash as recognised by dhis2.
So if you have for example a csv file containing many, many users, then you can incorporate a script along the lines of the attached genpass.tcl to generate the hash codes in bulk. Or just expand the java program to read the csv file and possibly even write into postrgres table. (Personally I prefer to do do things a little bit at a time and script through psql). Anyway thats up to you … the algorithm is here.
There are some security considerations. The hash algorithm itself is not great, but you are stuck with emulating what happens inside dhis2 so no point tinkering with that (MD5 must seem like plaintext to the NSA nowadays). A more important consideration is how to generate the 45000 passwords. I have used the makepasswd program to generate fairly cryptic random passwords (also in a script) but users didn’t like them, naturally. Randy initially assigned them things like password1, password2, password3 etc which is also not ideal.
I wonder is the self registration feature an option for you? Not that users necessarily pick good passwords anyway
I think Bob is the best source for this. I have some R scripts but the generated password is not always correct due to peculiar methods which spring uses to encrypt the passwords which elude me.
Here are some documents that Randy Wilson shared on the list - though they state for “Hashpassword: we have not yet found a quicker way to do this than to send the excel file to Bob Jolliffe or Knut Staring (HISP). There is a special algorithm they use to create the MD5 hash password, combining the username and the assigned text password.” Unfortunately I don’t remember exactly how I used to do it…would be good if you share a how to when you figure it out…
You must look at the source code of DHIS2 and Spring in order to understand it. It is not a simple hash, but a salted hash depending on the username and password together. This has been previously discussed on this list, but it is most clear by analyzing the source code.