Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CakeFest_2023_Passbolt_Keynote.pdf

Amanda Goff
October 11, 2023
8

 CakeFest_2023_Passbolt_Keynote.pdf

Amanda Goff

October 11, 2023
Tweet

Transcript

  1. $ whoami $ hostname @stripthis Cakephp user since v1 [email protected]

    Open-source password manager for teams www.passbolt.com /passbolt @[email protected]
  2. … and a terminal near you. Via official or community

    maintained CLIs, Ansible collection, etc. Or with just Curl and GnuPG! $> export SECRET=`curl --location --request GET '${PASSBOLT_URL}'\ --header 'Authorization: ${ACCESS_TOKEN}' \ --header 'Content-Type: application/json' \ | jq -j '.body.data' \ | gpg -q --no-tty \ | jq -j '.password` $> passbolt get 664735b2-4be7-36d9-a9f8-08d42998faf8 -----BEGIN PGP MESSAGE----- …
  3. Authentication? Asserting a user identity using something they: know (passphrase,

    password, pin) have (token, certificate, key) are (biometric) or do (typing pattern, gait)
  4. Password based authentication Using server side password hash comparison Client

    (Browser) Server GET /login 200 OK <html> login page Set-cookie: csrfToken POST /login {username, password, csrftoken} Enter username Enter password Enter login url Assert CSRF token Assert not logged in Asser user exist Calculate hash Compare hashes (Re)Start session 302 Found Location: /home Set-cookie: session Assert not logged in Render form
  5. Password based authentication - Credential stuffing. - Phishing. - Password

    loss. - Bruteforce (online) - Bruteforce (offline, in case of leak). ~ Adversary in the middle (network) ~ Password logging. ~ User enumeration Security issues:
  6. Password based authentication - Credential stuffing. - Phishing. - Password

    loss. - Bruteforce (online) - Bruteforce (offline, in case of leak). ~ Adversary in the middle (network) ~ Password logging. ~ User enumeration Security issues: + Checking against breaches & entropy ~ User training + Account recovery + Captcha (+GDPR) / WAF / Alerts + “Costly” hashing mechanism (bcrypt) + HTTPs pinned and well configured + Additional client side hashing? + Vague error messages & constant time? Implementation considerations:
  7. composer require bjeavons/zxcvbn-php namespace App\Model\Validation; use Cake\Validation\ValidationRule; use ZxcvbnPhp\Zxcvbn; class

    IsStrongPasswordValidationRule extends ValidationRule { public function rule($value, $context): bool { $zxcvbn = new Zxcvbn(); // $contextData prevent the password to match the email or name, etc. $contextData = $context['data'] ?? []; unset($contextData[$context['field']); $contextData = array_values($contextData) ?? null $strength = $zxcvbn->passwordStrength($value, $contextData); // 3 is safely unguessable (guesses < 10^10) // 4 is very unguessable (guesses >= 10^10) return $strength['score'] >= 3; } }
  8. “Magic link” authentication Using random token and email notifications Client

    (Browser) Server POST /login/start {username, csrftoken} 200 OK GET /login/complete/:user_id/:token Click on “lost password” link Assert CSRF Assert user Generate token Add email to queue Render form 200 OK Set-cookie: session Smtp Server Goto email Click on link Assert user / token relationship Assert token status Assert token expiry Invalidate token
  9. “Magic link” authentication ~ Phishing (email provider) - User enumeration

    - Man in the middle ~ Replay attack - Email logging / intercept Security issues: - Context switch, email delays, etc. UX issues:
  10. “Magic link” authentication ~ Phishing (email provider) - User enumeration

    - Man in the middle ~ Replay attack - Email logging / intercept Security issues: ~ User training + Vague error messages & constant time? + HTTPs required, no HTTP fallback + One-off use, expiry date + TLS for SMTP, relays, etc. Implementation considerations: - Context switch, email delays, etc. UX issues: - Email client “preview” counts as a click?
  11. “Magic link” tokens design lesson learned Schema id: uuid (PK)

    user_id: uuid (FK) token: char(128) (U) created: datetime expired: datetime|null type: enum(string) context: json(string) |null auth_tokens + Very strong entropy for tokens + Reusable, support multiple types (reset password token, email validation setup token, MFA recovery code, SSO settings validation, SSO code, SSO refresh token, etc.) + Expiry generally set by default, updated when consumed. + Context allows to extend authentication logic (example: user agent, IP, next/prev action, setting_id) + Purge after X days? Requirements
  12. “SMS” authentication Using random token and email notifications Client (Browser)

    Server GET /mfa/sms 200 OK POST /mfa/sms {code, csrfToken} Assert CSRF Assert user Generate token Add SMS to queue Render form 200 OK Set-cookie: session SMS Service Grab code Enter code Assert user / token relationship Assert token status Assert token expiry Invalidate token
  13. SMS authentication - Phishing - Adversary in the middle -

    Bruteforce - SIM Card swap - Phone theft (notif on lock screen?) - SMS interception - Delays in receiving SMS Security issues:
  14. SMS authentication - Phishing - Adversary in the middle -

    Bruteforce - SIM Card swap - Phone theft (notif on lock screen?) - SMS interception - Delays in receiving SMS Security issues: ~ User training ~ HTTPs required ~ Max failed attempts / throttling / Alerts ~ Choose a good carrier? ~ Set safe phone settings? Implementation considerations:
  15. MFA/TOTP authentication Time based one time password Client Server POST

    /mfa/totp {totp, csrfToken} Get TOTP Enter TOTP Assert user Assert settings Assert TOTP 200 OK Set-cookie: mfa Mfa required 200 OK Set-cookie: csrfToken Assert user Assert settings GET /mfa/totp
  16. MFA/TOTP authentication - Adversary in the middle (phishing site) -

    Adversary in the middle (network) - Bruteforce - Sync’ without encryption Security issues: - Lost TOTP UX issues:
  17. MFA/TOTP authentication - Adversary in the middle (phishing site) -

    Adversary in the middle (network) - Bruteforce - Sync’ without encryption Security issues: ~ User training + HTTPs required, no HTTP fallback + Max failed attempts / throttling / Alerts ~ TOTP app preference? Implementation considerations: - Lost TOTP UX issues: + Admin reset process? Another MFA?
  18. composer require spomky-labs/otphp use OTPHP\TOTP; use ParagonIE\ConstantTime\Base32; class TotpFactory {

    public static function generateTotpUri(IdentityInterface $uac): string { // RFC 4226 recommend a key length of 160 bits. // The key is represented as a base32 string, which stores 5 bits per character, // so the string in the QR code should be 32 characters (and without padding) $secret = trim(Base32::encode(random_bytes(32)), '='); $totp = TOTP::create($secret); // label: string shown below the code digits in TOTP app $totp->setLabel($uac->getUsername()); // issuer: string shown above the code digits in TOTP app $totp->setIssuer(self::getIssuer()); return $totp->getProvisioningUri(); } }
  19. composer require spomky-labs/otphp use OTPHP\Factory; class TotpVerifyForm extends Form {

    // @var ..\Model\Entity\MfaUserSetting Entity (or DTO) representing the user settings protected $settings; //.. Constructor, etc. public function validationDefault(Validator $validator): Validator { return $validator //.. after type, length, etc. check ->add('totp', ['isValidOtp' => [ 'rule' => [$this, 'isValidOtp'], 'message' => __('The TOTP is not valid.'), ]]); } public function isValidOtp(string $value): bool { // uri is something like 'otpauth://totp/alice%40google.com?secret=JBSWY3DPEHPK3PXP&foo=bar' return Factory::loadFromProvisioningUri($this->settings->getTotpProvisioningUri()) ->verify($value); }
  20. composer require bacon/bacon-qr-code namespace App\View\Cell; use Cake\View\Cell; use BaconQrCode\Encoder\Encoder; use

    BaconQrCode\Renderer\Image\SvgImageBackEnd; use BaconQrCode\Renderer\ImageRenderer; use BaconQrCode\Renderer\RendererStyle\RendererStyle; use BaconQrCode\Writer; class QrCodeCell extends Cell { public function display(string $provisioningUri): void { $renderer = new ImageRenderer( new RendererStyle(256), new SvgImageBackEnd() ); $writer = new Writer($renderer); $inlineSvg = $writer->writeString($provisioningUri, Encoder::DEFAULT_BYTE_MODE_ECODING); $qrcode = str_replace('<?xml version="1.0" encoding="UTF-8"?>', '', $inlineSvg); $this->set('qrcode', $qrcode); } }
  21. SSO OAuth2/OIDC authentication (code flow) Client (Browser) Resource Server POST

    /sso/start 302 Found Set-cookie: state GET /sso/redirect?code=..?state=.. Cookie: state=.. Click on SSO button Generate nonce Generate state 200 OK Set-cookie: session Authorization Server GET /authorize?client_id=..&response_type=code& state=..&nonce=..&scope=openid email&redirect_url=.. 302 Found Location: <redirect_url> Assert state POST /token?grant_type=authorization_code &code=..&client_id=..&client_secret=.. 200 OK {id_token,..} Assert JWT (signature, expiry, iss) Assert nonce Assert email, verified_email
  22. SSO OAuth2/OIDC authentication (code flow) - Cross-site request forgery -

    Replay attack - Adversary in the middle (network) - Service unavailable - User id confusion - Privacy (platform logging) ~ Phishing of SSO provider credentials? Security issues: + State + Nonce, JWT expiry + HTTPs required, JWT signature ~ Alternative login method? ~ verified_email, guid? + Security: alerts and SIEM integration Implementation considerations:
  23. composer install league/oauth2-client + Support multiple providers (Azure, Google, etc.)

    - Does not support mapping resource owner as id_token (JWT) - Mixed support for URL discovery using .well-kown endpoint Library choice considerations: + Assert the state with SSO provider settings versions ~ Make admin complete the flow before enabling SSO - Build SSO token expiry reminders (e.g. Azure) Other implementation considerations:
  24. Relying Party The website that wants to authenticate you Client

    The web-browser & client side software (JavaScript) Authenticator Proves you are you, either on the device (platform) or off device (roaming). CTAP 2.0 Client to authenticator protocol WebAuthn Web Authentication HTTPS FIDO2 Project A joint effort between the FIDO Alliance and the W3C Examples: iOS Keychain Microsoft Hello Yubikey Dashlane Examples: Chrome Firefox Safari Examples: Google etc.
  25. Passkeys A private-public keypair (credential) that can be used to

    authenticate and that can be synced across multiple devices (as opposed to hardware bound). Client data Private Key (Asymmetric Key) Sig Hash Sign Auth Data Sig Public Key (Asymmetric Key) Verify Client Data’ Parse & Compare Sign | Verify || Data sent Client Generated by authenticator
  26. WebAuthn authentication Assertion, e.g. authentication flow (login flow) Authenticator Client

    {authData, signature, user, ..} Relying Party Verify user Sign / create assertion 200 OK publicKey (PublicKeyCredentialRequestOptions): {challenge, rpId, allowCredentials, userVerification, ..} authenticatorGetAssertion() {rpId, clientDataHash, ..} POST /webauthn/assertion/options {username} POST /webauthn/assertion/response AuthenticatorAssertionResponse: {clientDataJSON, authenticatorData, signature, userHandle} navigator.credentials.get(publicKey) 200 OK Set-cookie: session Verify sig Assert RP ID etc.
  27. Registration on MacOS/Safari 🤔 “Currently, YubiKeys can store a maximum

    of 25 passkeys.” (if you've never entered a PIN when you registered your Yubikey you are not using resident keys).
  28. Recovery of passkeys (iCloud) “Passkeys can be recovered through iCloud

    keychain escrow, which is also protected against brute-force attacks, even by Apple. [...] To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed. Optionally, a user can set up an account recovery contact [...].” Ref. https://support.apple.com/en-gb/guide/security/sec3e341e75d/web
  29. Passwords security issues - Credential stuffing. - Adversary in the

    middle (phishing). - Passwordkeys loss. - Bruteforce (online) - Bruteforce (offline, in case of leak). - Adversary in the middle (network) - Password logging. ~ User enumeration Security issues: + Checking against breaches & entropy ~ User training ~ Account recovery + Captcha (+GDPR) / WAF / Alerts + “Costly” hashing mechanism (bcrypt) + HTTPs pinned and well configured + Additional client side hashing? + See small prints Implementation considerations:
  30. - Passkeys loss (device loss) ~ Physical Proximity (BLE, NFC)

    - Passkey management & review ~ Passkeys availability to admins? - User enumeration / Privacy ~ Root CA leak / rotation ~ Quantum computers? ~ more, see Security considerations Passkeys security issues Security issues:
  31. - Passkeys loss (device loss) ~ Physical Proximity (BLE, NFC)

    - Passkey management & review ~ Passkeys availability to admins? - User enumeration ~ Root CA leak / rotation ~ Quantum computers? ~ more, see Security considerations Passkeys security issues Security issues: ~ Account recovery? More passkeys? ~ Accept risk? ~ User training? Better UX? Alerts? ~ Better signalization of sharing props ~ Username-less design ~ Passkey rotations ~ PQC, crypto agility Implementation considerations:
  32. Passkeys issues - End user experience ~ Specs stabilization? -

    Authenticator gatekeeping? - Pay to play / Diversity? - Open-source ecosystem support Other issues: ~ UX Working group ~ Traction? ~ Monkey patching? Fines? ~ Get involved? ~ Get involved! Other considerations: