public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [RFC backup 0/6] Two factor authentication
Date: Wed, 2 Dec 2020 13:59:31 +0100 (CET)	[thread overview]
Message-ID: <1852852245.540.1606913971543@webmail.proxmox.com> (raw)
In-Reply-To: <20201202124812.GG7591@gaia.proxmox.com>


> On 12/02/2020 1:48 PM Oguz Bektas <o.bektas@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.




  reply	other threads:[~2020-12-02 12:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 14:56 Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 1/6] add tools::serde_filter submodule Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 2/6] config: add tfa configuration Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 3/6] api: tfa management and login Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 4/6] depend on libjs-qrcodejs Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 5/6] proxy: expose qrcodejs Wolfgang Bumiller
2020-11-19 14:56 ` [pbs-devel] [RFC backup 6/6] gui: tfa support Wolfgang Bumiller
2020-11-24  9:42   ` Wolfgang Bumiller
2020-11-24  9:51     ` Thomas Lamprecht
2020-12-02 10:56 ` [pbs-devel] [RFC backup 0/6] Two factor authentication Oguz Bektas
2020-12-02 12:27   ` Thomas Lamprecht
2020-12-02 12:34     ` Thomas Lamprecht
2020-12-02 12:48       ` Oguz Bektas
2020-12-02 12:59         ` Wolfgang Bumiller [this message]
2020-12-02 13:08           ` Oguz Bektas
2020-12-02 12:35     ` Oguz Bektas
2020-12-02 12:51       ` Wolfgang Bumiller
2020-12-02 13:15         ` Thomas Lamprecht
2020-12-02 13:07       ` Thomas Lamprecht
2020-12-02 13:35         ` Oguz Bektas
2020-12-02 14:05           ` Thomas Lamprecht
2020-12-02 14:21             ` Oguz Bektas
2020-12-02 14:29               ` Wolfgang Bumiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1852852245.540.1606913971543@webmail.proxmox.com \
    --to=w.bumiller@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal