Thoughts on Online Identity

Current Unfavorable Trends:

Immutable Usernames / Unnecessarily Publicly Visible User IDs

The inability to change usernames and the unnecessarily exposure of internal User IDs on the frontend.

Why these are disliked:

Obviously.

The Use of Centralized Authentication in Decentralized Scenarios

Typically manifested as the heavy reliance of global mainstream services (excluding certain totalitarian states) on email addresses and third-party logins (OpenID Connect). Conversely, in certain totalitarian states, this manifests as a mandatory reliance on mobile phone numbers and "National online identity authentication."

Why these are disliked:

They establish stronger correlations between disparate accounts, leading to further privacy erosion and even linking digital accounts to real-world identities. Furthermore, if control over the primary account is lost or erroneously transferred, account security cannot be guaranteed. Typical examples include the banning of email or third-party OAuth accounts, or the recycling of mobile phone numbers by carriers.

Using Mobile Numbers as the "Something You Have" Factor in Multi-Factor Authentication (MFA)

Specifically, the widespread use of SMS-based verification by mainstream services.

Why this is disliked:

It tethers the security boundary to a trust in traditional telecommunications networks. Vulnerabilities such as downgrade attacks on LTE/5G (forcing devices back to GSM) allow for eavesdropping and tampering. Additionally, the SS7 signaling network relies on a "walled garden" security model that assumes all internal participants are trustworthy—which is demonstrably false. In certain countries, carriers are even less trustworthy, especially given that mobile numbers are tied to mandatory real-name registration.

Account Recovery via Security Questions

Why this is disliked:

They are highly susceptible to social engineering attacks and are inherently prone to being forgotten by the user.

Proposed Best Practices:

• Identity Separation: If a username is required, the User ID and the Username must be independent. The ID should be system-assigned upon creation and remain invisible to other users unless absolutely necessary. The Username must be changeable at the user's discretion.
• Account Recovery Mechanisms: Robust account recovery must be provided. Email and/or mobile numbers should be treated as optional and non-recommended recovery methods. The recommended approach is the use of generated recovery codes (OTPs), which must allow for multiple regenerations. Regeneration must be classified as a sensitive operation requiring multi-factor re-authentication.
• Data Encryption: Account data must be protected by independent encryption keys. If the credentials are lost, the data must remain inaccessible (Zero-Knowledge). Combining this with the previous point ensures both account availability and data security even in the event of a malicious recovery attempt.
• Comprehensive MFA Support: Systems must support at least the traditional "Something You Have" factors: TOTP and public-key cryptography (e.g., FIDO2, TLS certificate login, SSH private key signature login, Passkeys/WebAuthn). Systems may optionally support "Something You Know" (Passwords) and/or "Something You Are" (Biometrics: face, fingerprint, palmprint, vein, or iris recognition). Users should have the autonomy to enable one or all of these factors. Simultaneously, support for multi-device registration and migration mechanisms is essential.
• Contextual Centralization: Centralized authentication services should only be utilized where there is a legitimate justification for centralized management (e.g., educational institutions or enterprises), provided that a centralized account is issued by the organization (avoiding the need for individuals to provide personal accounts). In all other contexts, centralized authentication should be avoided.

You've reached the end of this page. And you may Go to index or visit my friends.
About me and contacts
Except where otherwise noted, this site is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License