Red Sift

A Security Company’s Password Paradox

Just like PayPal, Red Sift’s login interface is another spectacle—where entering a password longer than 64 characters apparently crosses the line into the forbidden zone of “unwanted.” A curious restriction for services guarding sensitive financial or security data.

Sure, devs might want neat inputs; maybe there’s a rationale behind limiting password length (performance, interface design, or legacy integrations). But when security companies take this stance, it’s worth interrogating their logic.

Let’s retrace the steps when trying to use a 128-character password:

• Is “Fewer than 64 characters” a helpful hint, or just dry feedback?
• Is a “passphrase” (20+ characters) considered robust, or do they care if it includes special characters?
• Why even set a lower or upper bound? Must it be exactly 20? What if it’s longer and packed with entropy?

The real puzzle, as outlined in the PayPal deep-dive on password enshittification, lies in how password storage actually works.

Do Developers Truly Understand Hashing?

Modern password hashing algorithms (bcrypt, Argon2id, PBKDF2) are designed to take passwords of varied lengths and turn them into hashes of fixed size—whether your password is 8 characters or 512. The hash’s length doesn’t change, so there’s no valid storage excuse for rejecting longer passphrases. (SHA-256? Always 256 bits. Bcrypt? Always 60 characters. No matter the password length.)

High-entropy, lengthy passphrases should be encouraged, not blocked. Truncating or restricting password length actually diminishes user security, exposing them to dictionary and brute-force attacks.

Is the interface anticipating vulnerabilities like code injection? Or is the arbitrary length simply their “compensating control” for insecure handling elsewhere? Setting these caps is not a substitute for properly validating and escaping user input—which every competent dev should do.

Password security 101, per OWASP:

• Use slow, salted hash algorithms specifically designed for passwords (bcrypt, Argon2, PBKDF2).
• Allow long, complex passwords and passphrases.
• Apply proper input validation and field escaping (not just length checks).
• Consider rate limiting and strong authentication for additional protection.

Until major vendors embrace these best practices, users will keep bumping into arbitrary fences that do more to hinder security than help it.