Generator-jhipster: Changing default passwords

[mrts]

Overview of the issue

JHipster uses weak default passwords for generated users. As passwords are stored hashed and salted in the database, there's no easy way to generate a new valid password record manually.

Also, the database is seeded with initial data from src/main/resources/config/liquibase/users.csv (or src/main/resources/config/mongeeze/users.xml in case of MongoDB), so users need to figure out that they must change the password there.

This is why a helper command is needed for changing default passwords. It could be even called during project generation phase. A paragraph in the docs that explains how to change the usernames (in the initial data files) wouldn't hurt either.

Motivation for or Use Case

• Recent Equifax data leak with admin / admin credentials (are they using JHipster with default password :)?)
• Corresponding Stack Overflow question and answer

• Django command line password change utility - I suggest that the proposed command works the same way

• [x] Checking this box is mandatory (this is just to show you read everything)

[gmarziou]

I think it would be useful.
I also wrote a similar tool to generate long term JWTs that can be used in dev for using swagger-ui in services without a gateway.

About Liquibase users.csv, I think loadData could be part of a changeset conditioned on dev context, don't know for Mongeez.

[jdubois]

Yes we could have a small utility (maybe in https://github.com/jhipster/jhipster ?) that could be used to generate passwords, it would be useful for many people.

[gmarziou]

Personally, I put my tool in src/test/java so that it does not get bundled in prod and it can be generated and modified.

[gmarziou]

Such tools could be written in node to be able to run them when generating project but I think it would be better to write them in java so that they use same code as the app and can be easily run as a standalone program or from maven or gradle.

[jdubois]

Totally agree - I'd rather have them in Node but it's going to be way easier in Java.

[deepu105]

No offense to Java guys but I think writing a few lines of js script and calling it via the package.json script section would be way easier to do than getting the java code working in both maven and gradle

[deepu105]

And even easier would be to use something like https://www.npmjs.com/package/bcryptjs-cli

[jdubois]

Yes but you need the same algorithm - not sure you have this in JS.

[jdubois]

Sorry - OK let's do this in JS!

[deepu105]

we use BCryptPasswordEncoder on server side as well so we could do it with either https://www.npmjs.com/package/bcryptjs-cli directly using just a single line of script in the package json or using https://www.npmjs.com/package/bcrypt and a script file

[deepu105]

with the bcrypt cli its just one liner so probably it could be a tip as well as having a line in the package.json script like "generate-password": "bcrypt --" and calling generate-password mypassword doesnt add any additional value IMO
you could directly do

$ bcrypt mypassword
$2a$10$ckDge4zC6brAIMtM9x47zeG56MxG7UuaVzboIP0jkHuJP7d6jIEti

[gmarziou]

No offense to Java guys but I think writing a few lines of js script and calling it via the package.json script section would be way easier to do than getting the java code working in both maven and gradle

:) Remember I was talking of tools, mine is about generating tokens... but I will open my own issue.

[deepu105]

@gmarziou did you delete a comment coz I see email but its not here. Did you manage to get it working on windows?

[gmarziou]

Yes sorry, stupid me: I was trying with bcrypt rather than bcryptjs command.

[deepu105]

so what did you decide? do you think the cli tool is sufficient for this?

[gmarziou]

Yes for passwords it is enough, but maybe @mrts had something more ambitious in mind as it would seem by looking at the link he presented: Django command line password change utility. What I like here is also the documentation, could be a chapter of a book ;)

[gmarziou]

This could be also an opportunity to think about Liquibase contexts to avoid loading users.csv in prod profile.

Or maybe just create admin an user in prod at app startup if it does not exists and assign a one-time random password that could be logged, in a similar way as what Spring Boot does.

After all, this could be better than a CLI tool which is not well adapted to cloud deployment where you can't ssh to a server to run it.

[jdubois]

Yes doing a one time password looks great, but the issue is it will change when the app is re-generated. So that's really going to be annoying.

• I would like to keep admin/admin, at least in dev and test
• Then we should code a little JS script to generate passwords, including for the admin user -> it could be another small sub-generator, those are made for those use cases

[cbornet]

Maybe we could fail fast in prod if the password is admin ?

[jdubois]

@cbornet interesting idea!!! Yes that would solve the issue and be a nice security feature. Then it's one more request at startup (not sure if that matter).

[mraible]

If we change the password for admin, we're going to need a way to get the new password into our e2e and Gatling tests. Ideally, it could be encrypted.

[mrts]

We should also provide means to change passwords in the microservice projects components like JHipster Registry etc

[deepu105]

Let me summarize what needs to be done @jdubois @gmarziou @mraible @cbornet correct me if I misinterpreted anything.

1. we will continue to generate default admin/user account password as today so that dev is smooth
2. In prod profile, there needs to be a check to fail app startup if the default admin/user account password is admin/user
3. Add bcrypt as a dependency to the generated app and include a script in package.json "generate-password": "bcrypt --" and document the usage in the generated ReadMe file

[jdubois]

Yes, and the most important part is 3

[PierreBesson]

Also we could generate an encryption key for the registry (encrypt.key property) so that the encryption UI would works out of the box with docker/k8s and people can add secrets in encrypted form in their central config.

[pascalgrimaud]

In dev, for the developers:

• it's easier for all developers to have admin/admin for both, in dev and prod profile
• simple for protractor tests

In prod environment:

• you shouldn't keep the default password from your CSV files
• when we deployed to the final production, we logged in with admin and simply changed the password

If you really want to change the default password for developers, log into the app, change the default password, take the value in DB and put it in CSV file. Then, commit and share to all other developers.

Sure it could be a cool feature, but personnaly, it's not really worth the work.

[deepu105]

also, liquibase context feature could be used for this, that is what I do.
I have users-dev.csv which is loaded when liquibase context is dev and it uses admin/admin
I have users-prod.csv which is loaded when context is prod and uses a different tough password

Since liquibase supports this out of the box I just changed the schema like below

<changeSet id="00000000000002" author="deepu" context="dev">
        <loadData encoding="UTF-8"
                  file="config/liquibase/users-dev.csv"
                  separator=";"
                  tableName="jhi_user">
            <column name="activated" type="boolean"/>
            <column name="created_date" type="timestamp"/>
        </loadData>
        <dropDefaultValue tableName="jhi_user" columnName="created_date" columnDataType="datetime"/>
    </changeSet>
    <changeSet id="00000000000003" author="deepu" context="prod">
        <loadData encoding="UTF-8"
                  file="config/liquibase/users-prod.csv"
                  separator=";"
                  tableName="jhi_user">
            <column name="activated" type="boolean"/>
            <column name="created_date" type="timestamp"/>
        </loadData>
        <dropDefaultValue tableName="jhi_user" columnName="created_date" columnDataType="datetime"/>
    </changeSet>
    <changeSet id="00000000000004" author="deepu">
        <loadData encoding="UTF-8"
                  file="config/liquibase/authorities.csv"
                  separator=";"
                  tableName="jhi_authority"/>

        <loadData encoding="UTF-8"
                  file="config/liquibase/dataset/users_authorities.csv"
                  separator=";"
                  tableName="jhi_user_authority"/>
    </changeSet>

[jdubois]

@pascalgrimaud @deepu105 those are basically "how this is supposed to be done", but of course this hasn't been cleanly documented - maybe that's the first step we should do?
I agree this is quite a lot of work otherwise, and mostly for stupid people - if you're dumb enough to keep admin/admin then probably JHipster isn't the right tool for you.
BTW we should also better document you should change the JWT shared key, that's the same level of issue.
-> for me we should improve the "security" page for the admin password and the JWT shared key, and that would be good enough

[atomfrede]

As I don't have much time to code something I can take care of the documentation part, such that we can close this issue. I also think if someone puts an app in production without even thinking of the default passwords that one should not put something in production may. @deepu105 I didn't know about the liquibase environments, so maybe I can create a Tip for that too.

[deepu105]

Ok then lets document and close this

[mrts]

@atomfrede @jdubois although your point is valid, I would like to point out that humans rarely provision servers nowadays. How would you tell "open the browser, log in and change the password" to an Ansible or Chef script or Dockerfile?

[jdubois]

Yes indeed. That's why documentation is more important: it should be set up as an env variable or through Spring Cloud Config.
Personally I use a specific application.yml file I drop (with SCP) in the app's directory - very simple and easy!

[jdubois]

I just had a quick look at adding the bcrypt dependency in our package.json so people could generate passwords using an npm command: that's a very bad idea, as this requires node-gyp and well as OpenSSL. So this is going to crash on a number of platforms, and be really annoying, for just a handful of users.
So let's just document, indeed.