all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>, Oguz Bektas <o.bektas@proxmox.com>
Subject: Re: [pbs-devel] [RFC backup 0/6] Two factor authentication
Date: Wed, 2 Dec 2020 13:27:47 +0100	[thread overview]
Message-ID: <4c361a22-5caa-db5e-66b9-046638048fd5@proxmox.com> (raw)
In-Reply-To: <20201202105650.GA7591@gaia.proxmox.com>

Hi,

thanks for taking a look, some comments regarding your feedback.

On 02.12.20 11:56, Oguz Bektas wrote:
> we talked with wolfgang off-list about some issues, so here are
> some recommendations for the next version:
> 
> 1. increase the length of recovery codes for bruteforce mitigation
> 
> most websites use 12-16 characters for the length of recovery keys.

makes sense

> 
> 2. do not store recovery codes in cleartext (hash them instead, we thought
> hmac-sha256 is fine). the reason being that recovery codes can bypass
> other tfa methods so they shouldn't be visible

make sense, would expect them to be hashed

> 
> 3. don't store all the tfa information in a single json file.
> 

makes no sense to me, any reason you mention below can happen to arbitrary
files, so just adds complexity while not gaining anything.

> current version uses a single /etc/proxmox-backup/tfa.json file
> which holds all the tfa info for all the users. this is a single point
> of failure because:
> - file can be corrupted, causing tfa to break for everyone (no more logins)
> - file could get deleted, disabling/bypassing 2fa for everyone
> - file could get leaked in a backup etc., giving everyone's tfa secrets
> and/or recovery keys to attackers (bypass everything)
> 
> better is to at least create a file for each user:
> /etc/proxmox-backup/tfa/<username>.json or similar
> 
> this way the damage is contained if for example the config breaks
> because of incorrect deserialization etc.

Why would deserialisation be incorrect for one single file but magically
works if multiple files? Makes no sense.

> 
> 4. html/js injection in the description field on gui (fixed on staff
> repo already)
> 

Yeah, as always, Ext.String.htmlEncode is your friend ;)

> 5. notify user if more than X failed tfa attempts (password is already
> compromised at this point, so it's important to notify) and block IP
> for certain amount of time (fail2ban?)

we do not setup fail2ban but any admin can already if wished. Notification
can only work if the user has setup a mail in the first place - but yes, sou

> 
> 5.b also if recovery keys are available, limit amount of TOTP attempts
> for that user

what?





  reply	other threads:[~2020-12-02 12:27 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 [this message]
2020-12-02 12:34     ` Thomas Lamprecht
2020-12-02 12:48       ` Oguz Bektas
2020-12-02 12:59         ` Wolfgang Bumiller
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=4c361a22-5caa-db5e-66b9-046638048fd5@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=o.bektas@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal