V Thu, Jun 11, 2026 at 03:45:25PM -0400, Steven A. Falco napsal(a):
> On 6/11/26 02:37 PM, Simo Sorce wrote:
> > On Thu, 2026-06-11 at 08:34 -0700, Adam Williamson wrote:
> > > Maybe we should make people use 2FA anyway. For two reasons:
> > 
> > Except that there are people store their password *and* their sw
> > generated 2FA token in the same db/application making all of this
> > somewhat moot...
> > 
> > sadly whenever you improve security you find someone that self-defeats
> > it better.
> 
> Problem I see is that every web site naturally generates a different shared
> secret - I've got roughly 3 dozen and counting.  I don't know how to deal
> with that other than having a database somewhere that contains them all.  On
> the phone it's google authenticator or similar.  On the pc it's keepassxc or
> similar.
> 
> I played around with yubikey but found it unhelpful.  Maybe the newer ones
> can store lots of keys, but the old ones didn't.  And of course you need at
> least two keys in case one breaks and of course you have to keep them in
> sync.  And you probably still want a software backup in case a key wears
> out.  It isn't an easy problem.
> 
Exactly. OTP simply does not scale. E.g.
<https://www.yubico.com/cz/product/yubikey-5-nfc/> claims "OTP seeds: 2".

A problem with the hardware tokens is that you need to select which seed to
use. That can be done with a button on the device if you choose from
2 options. It cannot be done if you have to choose from dozens. You would have
to cotrol the choice from the computer and that would open another class of
problems, like hijacking valid keys for a foreign service.

The problem is elegantly solved with asymetric keys where you can safely use
a single key for inifinite number of services. TLS supports authenticating
clients with X.509 certificate for ages. Yet almost nobody implements it. All
Git hosting services support key authentication, yet they have a problem with
X.509. I don't get it.

-- Petr

Attachment: signature.asc
Description: PGP signature

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to