[pbs-devel] [RFC backup 0/6] Two factor authentication

[Wolfgang Bumiller]

> On 12/02/2020 1:48 PM Oguz Bektas <o.bektas at proxmox.com> wrote:
> 
>  
> On Wed, Dec 02, 2020 at 01:34:25PM +0100, Thomas Lamprecht wrote:
> > On 02.12.20 13:27, Thomas Lamprecht wrote:
> > > - file could get leaked in a backup etc., giving everyone's tfa secrets
> > > and/or recovery keys to attackers (bypass everything)
> > 
> > for the record, that does *not* "bypass everything", it's a *second* factor
> > after all. 
> 
> yes "bypass everything" was a bit of overstatement on my end.. :)
> > Further, if recovery keys are hashed they do not leak information.
> the totp secrets are stored without hashing or encryption so it'd bypass
> that one if file is leaked etc.
> > For others it varies, but I do not like that sort of blanket statement without
> > implying any reasonable vector at all, we and most unix system have such
> > information in one place /etc/shadow, our shadow in /etc/pve/ and consorts,
> > it needs clear documentation about what files are sensible (you should send a
> > patch for that) but that's it.
> > (and as said, splitting it up will not avoid leaking all of them in a backup vs. just
> > one of it).
> i was also thinking if it's a good idea to use a symmetric algorithm to
> encrypt the json file with that user's password. it would help in
> backup leak or similar cases, but could also be overhead (need to
> decrypt/encrypt the file everytime it's changed, need to re-encrypt if
> user changes password etc.)

If you mean the hash we store, then I'm against it, simply because the key
is lying right next to it.
If you mean the user's *actual* password, then
* we'd need to query the user's password even to just list the current TFA entries
* a lost password automatically means you have to re-register your second factors.
  (Not *much* of a problem, but kind of weird.)
* root could not read nor modify a user's tfa entries (also not a problem, but weird)

A mixed approach would keep the description & metadata in plaintext and store the
secrets in an encrypted form with an AAD cipher. But the only thing benefiting from
this really would be the TOTP entries. WA uses asymmetric cryptography already,
and if we hash the recovery keys, those should be okay, too.