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

[Thomas Lamprecht]

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.