Unless I'm missing something here, lacking parametrization is not the issue here. The issue is that it's obvious they are saving the password in plaintext instead of hashing it, otherwise the password would never get close to an SQL query to allow injection.
But since you can't guarantee that every programmer and contractor, including future ones, write proper SQL, it's nice to reduce the attack surface a bit.
Reduce the attack surface by running the password through a proper modern Key Derivation Function (KDF) such as Scrypt before passing it to the database, not by running it through a few regexes.
Nothing in their policy about what isn't allowed[0] and they updated their system one weekend and my password quit working because it had % in it. I called tech support over it and they offered no additional guidance.
Citi Student Loan website maxes out at 6 or 7 characters and is utter garbage on top of that. Worst case though, someone could pay my student loans for me I guess.
