Auth

Discovery

passkey reddit thread

what?

Authentication - who is this? (usually through cookies [sessions])
- user send request to server, the latter give a cookie, the latter will be used every time user make other requests
Authorization - can he do that? (usually through DB)
- Server check the kind of cookie an its permissions

Roll your own vs don’t

don’t
- main aurguments
  - needs many details that experts themselves miss
  - resource expensive

Theoretical Ways - DESC

Opinions on rank
- Realisticality
  - hardware keys - cost too much
  - passkeys - people still don’t know about them
  - e-mail auth - gives bad ux to users w passw managers
- Oauth - might be more insecure than pass/email
  - If I were an hacker, I would rather hack e-mail/google account instead of single services
- supporters & passive -
  - will make “unsecure” methods (like pass&email) viable
Main
- security keys/hardware keys
  - should support
    - FIDO w Passkeys
    - biometrics
- Passkeys - Favorite - asymmetric encryption
  - whathow?
    - private - public keys
    - private stays on ur device, public is sent to server (doesn’t matter if anyone gets it)
    - public key will send a “challenge” to device, and device will sign it with the private key and send it to public key that will confirm if everything is ok
    - details
      - at least on desktops, private keys are stored in a hardware component that’s separated from the OS
        
        In windows it should be the TPM
      - private key is unique for every website (not used for more than 1 website because it’s created at every registration in any new website/service)
        
        this might not count for every implementation
      - it creates a strong password itself (you don’t use the same data used to enable passkeys. Biometrics etc are never shared)
  - situations
    - gpt prompt
      - let’s say I use a passkey that follows FIDO standard and is setted up through biometrics using a phone. The hacker has full access of my phone (physicall & digitally) and he wants my private key. Should I be worried of him actually being able to steal my private key?
    - hacker have full remote & physical control
      - still need to hack/crack the enable system that
        
        could be biometric (hard to spoof)
        
        probably hashed and salted anyway if it’s PIN
        
        probably into a tamper-resistant hardware component
      - if you use the phone and hacker has access only to PC, it’s even harder
      - conclusion
        
        in most cases, unless the hacker has some really specific hardware compromising skills, it’s still really hard to compromize or steal the private key
    - phishing - “useless”, private key is never sent
    - keylog - nope
    - cams - maybe if you use the PIN, but also unlikely
    - physical access - unlikely, especially w TPM module
  - usually used with
    - face
    - fingreprint
    - pin
  - details
    - data is not shared w websites
    - favorite way to use it: bitwarden
  - cons
    - still need to be battle tested
      - e.g. that’s why it’s phishing resistant (not anti)
    - support and acknowledgment still needs to spread
      - it was boosted on start of 2023 through FIDO alliance
    - storing backups of private keys might not be simple
  - possible cons - great src
    - FIDO standard implementation is needed for sec
    - might have problems with
      - linux & fireforx
      - import/export passkeys
    - bluetooth BLE
    - priv key cloneable on phones, not on hardware keys
    - ecosystem is mostly google & apple, for now
      - bitwarden available
- OAuth2 & SSO + OpenID
  - OAuth - delegate auth to 3rd party service
    - requesting software can ask for permissions/data to 3rd party service oauth provider
    - possible cons
      - you can’t logout single users? - src
      - stealable access tokens to impersonate user
      - phishing to read 2FA codes
        
        forgot about the e-mail permission you gave to a 10 years old service? good luck
    - cons
      - lock-in (dependency)
      - less security
        
        it’s as secure as your google or whatever accout (and every account is linked to only 1 password)
        
        it’s like SSO in a way
      - less privacy
        
        google knows that you log-in to X website
      - less design/control
  - SSO - Signle Sign On - like Oauth, but cares only abt authentication
    - permissions doesn’t exist
    - uses SAML - Security Assertion Markup Language
    - centralized, so reliant on IdP (identity provider)
    - can contain & share info abt user depending on IdP and OpenID implementation (or non-implementation)
    - used for ecosystem of software where user can accesss it whole with only one acc and credentials (bad AF)
  - OpenID connect - layer on top of OAuth/SSO to give requester info abt user
    - open source, and decentralized protocol
    - used to get name, surname, e-mail, etc
    - how?
      - gives identity token (JWT) w requested data
- E-mail only auth - (log-in through link in ur mail) - src
  - Considerations
    - better than password, worst than stuff like passkeys
    - use it when you want more security and users would accept this over password flows
  - types
    - magic link
    - magic code
  - cons
    - user needs to have both phone & e-mail secured (MITM)
    - reliant on service/code used to send e-mails
    - Recovery Challenges
  - potential cons
    - UX
      - some people think it’s not convenient - src
      - are often time-limited for security reasons
  - pros
    - in classic e-mail and password if you have one of the two you have control of the acc (recover password). Here you can only log-in in 1 way
- cookies/session & token based/JWT
  - vulerabilities to take into account
    - XSS
    - CSRF
  - JWT
    - can store more info
    - usually stored with client so more scalability
    - less flexibility in how you store data
    - data is visible (not encrypted?)
    - bad if you need to store a lot of data
      - then every request will be massive
    - How to secure them?
      - Need to set up blacklist
        
        you can’t remove data from JWT (need to wait to expire)
      - pay attenction to where you store it
        
        never use localstorage (XSS)
        
        prefer http cookies (lookout of CSRF)
        
        in memory through refresh tokens
  - Cookies
    - reduces load on client
    - can actually store data as you want
    - http only
    - idk?
      - domain root
      - sameSite strict
      - cookie with a unique ID as a session identifier
- email&password - hard implementation
Supporters
- Biometric
  - Recognition
    - Facial
    - Voice
    - Eye
- Certificate Based - Mainly using hardware
  - software
    - operating system’s certificate store (e.g., Windows Certificate Store, macOS Keychain) or in secure software containers
  - hardware
    - cards
    - USBs
- 2FA
  - better if using an app
  - usually needs back-up codes to prevent loss of device
- TOTP - Temporary One-Time Passwords
  - usually needs back-up codes to prevent loss of device
  - channels where OTPs are served
    - apps (preferred)
    - e-mail
    - SMS
- KBA - Knowledge-based Auth - answer security questions
Passive
- Captchas
- communicating sus activity w logs
- rate limiting - to prevent brute force
- reauthentication
  - time based credentials expiration
  - Verifying the user’s identity under specific conditions or when accessing sensitive operations or resources. (like github when adding collaborators)
- extra checks
  - if admin is trying to create another acc with same admin credentials
- Extra Privacy risky
  - location
  - hardware detection - detects common devices in use
  - fingerprinting
  - Behavioral Biometrics

Theory

Criterias
- Good opinion on pricing
- 2FA
Principles
- MFA - Multi Factor Auth - use more auth methods togheter
  - Knows - password
  - Has - hardware
  - Is - biometrics
- Risk-based Authentication - score based auth
  - gives score based on how many stuff user has/has not passed on any auth method
- zero-trust
Other
- FIDO2 auth - protocol that uses asymmetric encryption src
- e-mail or SMS are usually one of the worst secure channels
  - anything related to this, is probably unsecure

Libraries&services - good src - 2

lucia auth - less abstracted way of nextauth
- bad
  - mainly developed by only 1 person
  - doesn’t support JWTs
  - 7k stars only
supabase - easy to setup, a lie that you can self host
nextauth
- what? - like react-form but for auth in next.js.
- bad
  - currently V5 is in beta and is an important and big change (rewrite)… 06/May/2024
  - only 1 guy is doing most of the work and he’s not even a security expert - github, src
    - but other 2 guys seems active enough
  - some people think that making your own auth is better - src
  - doesn’t work on mobile & huno edge workers - src
  - actually makes it harder to implement email-password auth for security - src
  - docs deemed as labyrinthic
  - less flexibility compared to lucia because of heavier abstractions
- auth.js is just next-auth V5
  - big rewrite that also adds framework agnostic (with similar APIs though)
- if most users are free
- FOSS, you own everything
passport.js - mainly used in express, old & famous
- bad
  - seems mantained only by 1 guy - src
idk
- ory
- goauthentik
- keycloack - foss, redhat mantains it, webgui
  - con
    - bad docs & incosistant because speedy dev - src
Hosted
- closed source
  - Clerk - nextauth & auth0 combined expensive
    - gives even UI to manage, let people log-in, etc
    - Lock in? 1 2
    - tiers
      - free
        
        clerk brending present… need 25/m to change
        
        10k active users
        
        unlimited login
  - AWS Cognito -lock-in, bad rep
  - Auth0 - cloud place where to put auth data
  - pricey AF compared to Cognito
  - firebase
    - tiers
      - free

Implementations

Ed's Garden

Explorer

Auth

Graph View

Backlinks