[pbs-devel] [RFC backup 0/6] Two factor authentication
t.lamprecht at proxmox.com
Wed Dec 2 14:15:56 CET 2020
On 02.12.20 13:51, Wolfgang Bumiller wrote:
>> On 12/02/2020 1:35 PM Oguz Bektas <o.bektas at proxmox.com> wrote:
>> On Wed, Dec 02, 2020 at 01:27:47PM +0100, Thomas Lamprecht wrote:
>>>> 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
> FWIW TOTP secrets can't be hashes since they're supposed to be,
> well, a shared secret
yeah sure, above talks about recovery keys though.
>>>> 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.
> Complexity is the wrong argument. The question is mainly whether we prefer
> lots of small or one big file. For PBS it's not even that important. It'll
> be more important when we add bindings for this to PVE where the file sizes
> are limited.
No complexity is seldom the wrong argument, it may not be enough on its own though.
> With a file per user it's also easier for an admin to work on the files
> directly. And if we want to add counters, limitations or eg. store date & ip
> of the last time an entry was used, we won't be locking one big file at login
> time. Not that I expect millions of concurrent logins to be happening ;-)
We create a confusing split view, all user info are concentrated into single files
per type, user.cfg, acl.cfg, shadow.json, etc. just TFA wants to be a unicorn and
split it up in files per user - seems rather inconsistent.
And, admins should resort to working on files directly as a last measurement, CLI
tools and the GUI should be preferred, *always*, so that's a moot point.
More information about the pbs-devel