Can sites which check your password as you type pose a security risk?
Modern cryptosystems are generally not susceptible to known-plaintext attacks. In terms of encryption algorithms, there are basically 3 algorithms commonly in use in TLS:
- AES
- RC4
- DES (in 3DES)
All 3 of these are believed to be resistant to known-plaintext attacks, and have been well studied for such attacks.
The one thing I would wonder about are side-channel attacks. There's (potentially) several bits of information being leaked about your password, but the ones I can think of all require an attacker who is able to observe your traffic (of course, so would the known-plaintext attack you asked about).
If TLS compression is enabled (which it really shouldn't be, given the CRIME attack) and an attacker is able to correctly guess all of the other data sent in your request (which is not hard if there are no unique cookies) then it's possible they might be able to figure out your password by sending substrings and seeing which ones compress to the same length as your password.
Timing attacks. Depending on how quickly the JavaScript sends requests to the server after you type keystrokes and your typing patterns, an attacker may be able to discern (or at least narrow down) what characters you're typing based on the intervals between packets (which indicates the intervals between keystrokes). This attack was demonstrated against SSH by Song et. al. in 2001, so it's not exactly novel, just novel for HTTPS. (HTTPS is generally not real-time, but what you're describing makes it approximately real-time.)
The length of the password. The attacker could measure the number of packages sent to the server and their sizes, and make a good guess about the length from the number of typed characters. Knowing the length of a password reduces the base by 1. So instead of having to guess 11^5 passwords, the attacker only has to guess 10^5 passwords for numeric passwords.
Overall, this isn't what I would worry about. It's far more likely this website is vulnerable to XSS, SQL injection, session management vulnerabilities, etc., than it is that an attacker will use this back-and-forth technique to compromise your account.
If nothing else, it's an API for checking passwords without any time delay. It has to be: if they had a time delay after every incorrect guess, it would defeat the point of live-checking the password. If you password is "password", then the server has to check seven incorrect passwords before reaching the correct one, and you can't afford to have a delay after every keypress. A user could bypass this by cut/pasting the password from somewhere else, but this isn't behavior that we want to encourage.
For similar reasons, this API almost certainly doesn't block people after repeated incorrect guesses. Even if it does, the threshold is probably unacceptably high. A malware-based cracker would work especially well here: it could scrape a user's hard drive for likely passwords, then emulate cut/paste so that it only wastes one guess per entire password instead of length - 1 guesses.
The people who implement this kind of checker mean well, but the concept behind it is fundamentally flawed. No one should be doing it. You're just opening yourself up to malicious attacks, for no real UX gain.
Maybe a silly question but are you certain you're not getting a ✓ meaning that the password you have entered has met the minimum requirements for the sites password policy? Such that the client side code is saying "yes, this is a valid password and I will accept it, although I have not yet validated the correctness." When you enter the password as "password1234" is it still a ✓ ?