BAD PASSWORD error when using database username as Linux system user password

[Eprince-hub]

:one: What happened that was unexpected Creating Linux system user for postgres throws an error

BAD PASSWORD: The password contains the user name in some form

:two: What were your expectations Create a system user for postgres without issue

:three: Your guess of what the problem is Linux expects that the password for the system is unique and would throw an error otherwise

:four: A list of things you have tried to solve it Check the learning platform's cheatsheets for postgres Creating the user with a password the same password I used in the database as suggested by the cheatsheet throws the error below

sudo adduser next_js_e_commerce_store;
Adding user `next_js_e_commerce_store' ...
Adding new group `next_js_e_commerce_store' (1002) ...
Adding new user `next_js_e_commerce_store' (1001) with group `next_js_e_commerce_store' ...
Creating home directory `/home/next_js_e_commerce_store' ...
Copying files from `/etc/skel' ...
New password: 
BAD PASSWORD: The password contains the user name in some form
Retype new password: 

After using an entirely new unique password, the system asked the questions below, which I only pressed enter on all, the system user was created, and I can continue with postgres

Changing the user information for next_js_e_commerce_store
Enter the new value, or press ENTER for the default
    Full Name []: 
    Room Number []: 
    Work Phone []: 
    Home Phone []: 
    Other []: 

Todo

• [ ] Research a method for creating Linux system user without the above questions
• [ ] Update system setup guide + cheatsheet for Linux users

[ProchaLu]

After some research, i was able to figure out where the error is coming from. It seems like the error message comes from the Linux-PAM library (Pluggable Authentication Modules). We don't have a guide to add this library, or recommend the usage of this library.

I have reached out to Linux users for confirmation on whether this library is indeed being used. As a workaround if this library is used, maybe it is possible to temporarily relax the password complexity policy just for the duration of setting the password, or maybe it is possible to use the chpasswd Linux command?

[ProchaLu]

I got the confirmation from a student that they are using libpam-modules version 1.4.0-11ubuntu2.4. This module provides this PAM library, which is used to manage authentication tasks on Linux systems.

~ dpkg -l libpam-modules
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                 Version           Architecture Description
+++-====================-=================-============-========================================
ii  libpam-modules:amd64 1.4.0-11ubuntu2.4 amd64        Pluggable Authentication Modules for PAM

Additionally, @CornaSn mentioned that this error message is only a warning, and after this warning you can use the same password as the username without PAM throwing an error.

BAD PASSWORD: The password contains the user name in some form
Retype new password: 

[karlhorky]

As a workaround if this library is used, maybe it is possible to temporarily relax the password complexity policy just for the duration of setting the password, or maybe it is possible to use the chpasswd Linux command?

Additionally, @CornaSn mentioned that this error message is only a warning, and after this warning you can use the same password as the username without PAM throwing an error.

hmm, it's not so bad then, but it does feel like a workaround for Linux (and reducing security - even in a workaround - seems like a weird thing for us to advise)

what are our other options?

1. what if we make Linux different (since the setup for Linux is already different)?
   • downside: Linux is different, which is confusing and both teachers and students need to remember
2. what if we start setting database passwords on all OSes which don't contain the username?
   • downside: it may be a bit annoying to have to type in a password with psql and sometimes mess it up. can we make an elegant local database password rule that stays simple and is easy to remember? (security is not super important because this is a local database)

cc @Eprince-hub would be good to get your opinion here too

[ProchaLu]

1. what if we make Linux different (since the setup for Linux is already different)?

It is already different, but I wouldn't make it more complicated for the Linux users. Linux users are typically comfortable with its unique setup but introducing more steps might lead to confusion and dissatisfaction (Why did I choose Linux..., etc). As teachers, it's important to consider the impact on our teaching workflow as well. Adding complexity means more to manage, and we have to remember these additional steps. Maintaining simplicity is beneficial for students and teachers.

2. what if we start setting database passwords on all OSes which don't contain the username?

Setting up a different password that doesn't contain the username can be a good idea, but as mentioned in this comment above it can be a bit annoying, and students can also mistype the password. To avoid errors, we could implement straightforward and elegant password rules with a format that is easy to remember and reduces the likelihood of mistyping. Maybe this change can also encourage students to use better security practices.

Simple password rules can be:

• Passwords must be at least 12 characters long
• Passwords must include at least three of the following:
  • Uppercase letters (A-Z)
  • Lowercase letters (a-z)
  • Numbers (0-9)
  • Special characters (e.g., !, @, #, $, %, ^, &, *)
• Passwords should not contain common words or easily guessable information (e.g., "password", "12345")
• New passwords should not match any of the last passwords used

[ProchaLu]

After some research about PAM-Linux, I'm reconsidering whether we should adjust our approach to teaching about local database credentials. PAM allows for flexible and dynamic configuration of authentication mechanisms, as described in the Ubuntu manuals. In other words, a Linux system administrator is free to choose how individual applications will authenticate users, they are likely aware that they will need to adapt their setup accordingly. Given this flexibility, it might not be necessary to alter our current teaching method.

[karlhorky]

there's still a problem described above though, which needs to be addressed