[Talk Notes] User Authentication Flows and Fundamentals

Talk notes from this event:

https://nishinomiya.connpass.com/event/367811/https://nishinomiya.connpass.com/event/367811/

---

Authentication: Authentication & Authorization & Session Management

• Authentication: proving who a user is
• Authorization: deciding what a given user can do or see
• Session management: state based on authentication (logged-in status, etc.)
• Why the distinction matters (separation of concerns, safer design, avoiding misuse, etc.)

Authentication

What Authentication Is

• The first authentication on HTTP/the web (arguably): "Basic authentication"
  • Apache default .htpasswd
    • Minimal auth as a permission boolean
    • Base64 encoding / plaintext storage / no session management!
    • Still used today as "security that is OK if it leaks"
• Authentication is often compared to "does this key fit the lock?"
• Whether you may enter—not strictly unique identification
• Lose the key, replace the key—that is the idea

Stepping Up to User Authentication

• Different key per person = user authentication

• Main approaches

  • Higher implementer risk
    • Password authentication (dictionary = unique keyword + password)
  • Lower implementer risk
    • UUID authentication common in mobile apps
    • Multi-factor authentication (MFA, 2FA)
    • OAuth / OpenID Connect
    • Passwordless authentication

• Typical password authentication

  • Email address + password pair
  • Why email address?
    • Verifies ownership and is unique
    • Send reset URL when password is forgotten
    • No separate marketing email question
    • Users forget less (you hope)
    • Fundamentally any unique username works
  • Why password?
    • Only the user should know it (you hope)
    • No special device—low account creation cost

• Implementer risk

  • You hold the key pair—always breach risk
    • https://rocket-boys.co.jp/security-measures-lab/unauthorized-access-to-so-net-accounts-some-user-email-addresses-accidentally-changed/
    • https://www.itmedia.co.jp/news/articles/2410/23/news133.html
  • "Manners" to reduce risk
    • Admins should not know what they should not know
      • "Show password" seems convenient for support
      • You should not know passwords—build password reset
        • To match user ID and password
        • Hash (one-way, unlike encryption) for comparison
        • Store user ID plaintext for uniqueness; hash password only
        • User ID needed to distinguish users with the same password
  • Email + password pairs are reused—leaks may work on other sites
  • Is hashing enough?
    • Focus on the password before processing
    • Password complexity
    • Brute-force and dictionary attack mitigation
    • Password reset can be a security risk depending on implementation…

• Since we touched implementation, authorization & session management too

• Authorization

  • Authentication: key fits the lock / Authorization: which rooms you may enter
  • Representative authorization models
    • Role-based: roles (AWS IAM is easy to picture)
    • Attribute-based: department, location, payment status, etc.
    • Access control lists: per resource—honestly unmaintainable

• Sessions

  • Requiring the key every request means users must store the key too
  • Before encryption—absurd
  • Like an entry pass instead of the key
  • Server-side session or token-based (stateless)

• Are lower-risk approaches always better?

  • UUID authentication common in mobile apps
  • Multi-factor authentication (MFA, 2FA)
  • OAuth / OpenID Connect
  • Passwordless authentication

• Use external services for authentication

  • Firebase Authentication
  • Auth0

• Privacy policy and disclosure requests

  • Telecom carrier disclosure obligations
  • Provider liability limitation law (Japan)
  • Rolling your own auth often costs more in risk than engineering
  • Draw the line on where your responsibility ends