initial infradmin account security

[jakubmanczak]

"admin admin" is famous for being the go-to first try when trying to access administrative accounts, and that's how the infradmin account is set up out of the box on the first run of the program. I don't think implementing security rules for accounts (like "change-this-password-next-login") is worthwhile at the moment, but replacing the initial password for the account is literally 5 minutes worth of work.

A replacement I literally have the code for ready (because that's how it works in Quote Engine) would be to generate a short series of characters after startup and set that as the password, logging it in the console. Something like S0FD4GF3Q, more or less. Short, easy to copy or type while looking at console output, but very much less predictable. Now this would be safer out-of-the-box, for the one login, but it's short and thus easy to crack.

Thus arises the philosophical question:

Would making the default infradmin password be Safer make infradmins Complacent and Reluctant to update their passwords, more so than if we used AdminAdmin, or would it not, thus just being the logical thing to do?

[jakubmanczak]

I admit this is quite forward-thinking, but there is also the matter of bots automating attacks on discovery of new addresses with live services. A slow-moving infrastructure admin (or just one that doesn't change it immediately) combined with the search potential of AIs used for attacks makes me now sure this randomized password approach is the correct path.

It's not a priority since nothing here is usable yet, but it definitely can't stay this way until the project is actually usable.

[Mateusz-Dobrzynski]

I did some research and according to my understanding of A07:2021 – Identification and Authentication Failures using credentials other than admin/admin seems in order.

However, letting the admin use a randomly generated password printed to console also sounds like a bad idea (still better than admin/admin, though). My idea would be to enforce a manual password creation upon deployment (similarly to how one would do installing an OS). Would it be possible to prompt the admin to enter a password in console and configure their account this way without keeping this password in the log?

[jakubmanczak]

Probably. We'd obviously not emit that to the in-system logs. There's Linux commands that register keystrokes but don't keep them printed to the console output (eg. the password prompt on su, which works via no-echo mode). Both the console-printed randomized password as well as inputting it via tty would get in the way of automating setting them up, however, e.g. via docker compose or however else. Maybe we could try an environment variable that's read on first run and can be deleted later? This still requires manual deletion, but it would create less friction.