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

[Oguz Bektas]

On Wed, Dec 02, 2020 at 01:59:31PM +0100, Wolfgang Bumiller wrote:
> 
> > 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
yes
> * 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)
yeah...
> 
> 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.
but this actually would make sense, i like that approach as it would
solve the issues you previously pointed out and keep it relatively
secure (very much in comparison to just keeping the secrets in
plaintext)
> 
> 
> _______________________________________________
> pbs-devel mailing list
> pbs-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
> 
>