21–24 of 24 posts
E-trade: Your password can’t be >32 chars. Their 2FA TOTP gets concatenated to the end of your password. Got a >26 char password? You’ll be locked out after enabling 2FA. No worries, though, you just call support, provide your email, and they disable 2FA for you..
E-trade: Your password can’t be >32 chars. Their 2FA TOTP gets concatenated to the end of your password. Got a >26 char password? You’ll be locked out after enabling 2FA. No worries, though, you just call support, provide your email, and they disable 2FA for you..
By far the most frustrating password-handling sin I've encountered is when a website silently truncates the password field to some fixed length. This is especially bad when you use a password-manager, as the password-manager will remember the full length password, which will be different than the truncated password the website is using. This wouldn't even be much of an issue if each website was at least consistent ab…
It's bad enough when that only applies to the length, but at least you could theoretically still log in once you knew what length it was truncated to. I've seen at least one banking site which had a narrower set of permitted symbols on the login page than the new account page. (Specifically, the login page didn't allow parentheses, but the new account page did.) Entering the correct password resulted in a form validation error, and of course if those symbols were removed then you still couldn't log in because it wasn't the right password.
Fortunately the login page's validation rules were all client-side, and thus easily bypassed via devtools with basic JS debugging techniques. Once logged in you could change your password to something the login page would accept without messing with the scripts.