Re: [pmg-devel] [PATCH pmg-api 0/1] user config: password: allows (gost-)yescrypt, hashes

[Samuel FORESTIER <samuel+dev@forestier.app>]

Hi Stoiko !

Thanks for your feedback, my responses inline.

BR

Stoiko Ivanov wrote:
> It is possible to create a user in the PAM realm (just like in our other
> products) - then you can simply login with the user - and their password
> should be checked by PAM. This has the advantage that you do not duplicate
> the password information and it stays consistent.
> 
> Currently creating users with realm PAM in the GUI is disabled (afair
> simply because we haven't seen reports where people would want to have
> many system-users as users in their PMG), but this could potentially be
> allowed - if there is a use-case which benefits from this.
> see: https://bugzilla.proxmox.com/show_bug.cgi?id=6488 for the request to
> hide the realm (expecting it not to be needed)

Indeed it would have been possible to do so, but as you pointed out, PMG 
currently doesn't honor system users through the PAM realm (bar root 
itself, mainly for node bootstrapping and to limit the number of 
passwords, I guess).

> What is your use-case - how do you create the users on the system, and
> would there be any upside for you to keep 2 copies of the password
> (compared to having the user@pam directly ask PAM)?

In my use case, PMG users are provisioned through a system configuration 
manager, which doesn't know password clear texts (yescrypt hashes are 
directly passed to shadow). These users are then synchronized from PAM 
to PMG realm, by still using their hashed passwords.
As of PMG 9.0, this patch is the only quick win I've come up with so far.

> Regarding the patch itself allowing other password-hashes (and maybe
> changing the default to yescrypt - as currently recommended by mkpasswd)
> might be ok.

Awesome ! No strong opinion about improving consistency across other 
Proxmox' products or _simply_ applying this patch to PMG, to extend 
UserConfig compatibility with more CRYPT(5) supported hash types.

 From a security point of view, I second your idea of defaulting to 
yescrypt in the future, maybe in the next major PMG release (according 
to your roadmap and "important" changes policy regarding semantic 
versioning).