Email account that works for this mailing list _and without a cell phone number_

[Jeffrey Walton]

On Sun, Oct 19, 2025 at 7:56 AM Ralf Mardorf via ubuntu-users
<ubuntu-users at lists.ubuntu.com> wrote:
>
> On Sun, 2025-10-19 at 01:52 -0400, Jeffrey Walton wrote:
> > I don't even have a cell phone.
>
> Neither do I.
>
> > I now use a device-based authenticator -- a YubiKey.
>
> I have one that is from and for things related to my employer. It's
> currently lying around unused, which is not my fault.
>
> # systemctl start pcscd.service
> # exit
> $ ykman info
> Device type: Security Key NFC
> Firmware version: 5.7.4
> Form factor: Keychain (USB-A)
> Enabled USB interfaces: FIDO
> NFC transport is enabled
>
> Applications    USB             NFC
> Yubico OTP      Not available   Not available
> FIDO U2F        Enabled         Enabled
> FIDO2           Enabled         Enabled
> OATH            Not available   Not available
> PIV             Not available   Not available
> OpenPGP         Not available   Not available
> YubiHSM Auth    Not available   Not available
>
> In my private life, I can't think of anything that such a key could be
> good for.

The output above shows you two things it is good for.  The first is
FIDO protocol support:

    > FIDO U2F        Enabled         Enabled

That's 2FA using HOTP and TOTP.  HOTP and TOTP are based on shared
secrets.  It is essentially the equivalent of a 2FA app that runs on
your phone and generates the codes to use as a second factor.

The second is FIDO2 protocol support:

    > FIDO2           Enabled         Enabled

That's 2FA using public key crypto.  The organization (or server) has
your public key, and you use the private key to respond to challenges.

In both cases, the secrets -- like a shared secret in FIDO protocol or
the private key in FIDO2 protocol -- remain in the device.  An
attacker cannot exfiltrate them and then impersonate you.

And to back up a bit, the three security goals of a second factor are:

    * uniqueness or randomness
    * phishing resistance
    * replay resistance

A static password does not meet any of the goals.  It completely fails
on all three goals.  It is best to pretend a static password does not
exist, and evaluate things using your second factor.  Or put another
way, assume the attacker already knows your static password (which is
not a stretch given the data breaches we are subject to every year).

Your YubiKey meets all of the goals.  For example, suppose you get a
phishing email asking for your password and second factor.  You visit
the site, cough up your static password, and press the key on the
YubiKey to provide the second factor.  But guess what?  The attacker's
site is a different origin, so the YubiKey does not provide the second
factor from your employer, bank or email.  Your employer, bank and
email are all different origins -- your employer's widgets.com is a
different origin than bank.com, and a different origin than email.com.
And if the attacker captures a past second factor, it cannot be used
in a current challenge.

Your YubiKey is very powerful.  It is unfortunate that your employer,
your bank, and other merchants you do business with do not support it
or take advantage of it.  But that is expected when you are dealing
with Developer-2-Developer security.  Developer driven security is
some of the worst security you will come across.

> I can use OTP for one German authoritie. For OTP, I use GNOME
> Authenticator, among other things.
>
> PayPal, a US company, relies on SMS to mobile phones here in Germany.
> IOW no NIST standard here.

Germany will have its own authority, similar to NIST.  Google tells me
it is Bundesamt für Sicherheit in der Informationstechnik (BSI), but I
don't know if it is correct.  The German authority has probably
published similar standards.

Jeff