Rafał Rothenberger's wroclove.rb 2022 talk about security edge cases in Devise. Covers: (1) bcrypt background — salt vs. pepper, and how bcrypt is a password-hashing function with a fixed 72-byte input that null-terminates C strings, meaning '72 A's' and '72 A's + X' produce the same hash; (2) how Devise's 128-char password length default plus appending a pepper at the end allows attackers to leak the pepper byte-by-byte by registering with 72-N-char passwords and brute-forcing the remaining pepper bytes via a simple login form; (3) fixes — switch to Argon2id (2015 PHC winner, ~4 GB input limit, native salt+pepper support, OWASP-recommended), enforce a 72-byte limit in Devise, or preprocess passwords with HMAC-SHA256 (never plain SHA, to avoid password-shucking) being careful about null bytes and 72-byte truncation after base64 encoding, or encrypt with AES (Dropbox-style, allows pepper rotation); (4) API authentication with devise_token_auth — opaque tokens, works alongside Devise views, now uses a standard Authorization header (released 10 September); (5) refresh tokens stored in HttpOnly, Secure, SameSite=Strict cookies to prevent JS leakage and MITM over HTTP, including Rails cookie syntax, refresh flow, CORS with credentials: true, and Ionic quirks; (6) tokens are passwords — hash them in the DB, set expiry, limit quantity; (7) enumeration attacks on registration, password-reset, confirmation and login forms — prevent by using neutral messages and moving the existence-check to a background Sidekiq job so responses take constant time, defeating timing-based enumeration; (8) rate-limit login forms by email (with an IP fallback to prevent lockout-based DoS). Q&A: using Auth0 vs. Devise, and why the speaker is talking publicly before upstreaming (emailed Devise 3 months ago, no reply; breaking security APIs is costly for users who only update packages).