15

Some sites that I use check my password as I type it into the login (not registration) form. So, for example, to begin with I might have:

Username: sapi ✓
Password: passw ×

and by the time I've finished typing, the site already lets me know that there were no mistakes:

Username: sapi ✓
Password: password123 ✓

Submission of the form is still required to actually log on.

Let's assume that this is not done on the client side (eg, by informing the client of the hashing algorithm and target hash); such an approach would obviously be unsafe, as it would allow you to obtain an arbitrary user's hash.

Assuming that the communication is encrypted, can checking the password letter by letter as it is typed pose a security risk?

My main area for concern is that doing so involves repeatedly transmitting similar (sub)strings:

  • some overhead data + the first letter of the password
  • some overhead data + the second letter of the password
  • ...
  • some overhead data + the entire password

This makes the plaintext of each communication to some extent deterministic (or at least, related to that of the previous and next communications).

I know that some encryption algorithms are vulnerable to known-plaintext attacks, although I'm not sure if SSL is one of them. I also don't know whether the level of knowledge gained here (which is obviously much less than for a known-plaintext attack) is sufficient to decrease the entropy of the output.

I guess I have two questions:

  1. Is this a security risk with standard web encryption algorithms (basically https); and
  2. If not, is there a class of algorithms for which this might pose problems?

I've added a clarification to the question that I'm referring to a login form, not a registration form. In other words, the client cannot simply validate the password against known length/complexity rules using JS; the account already exists and the checkmark only appears for a correct password.

| improve this question | |
  • 2
    What do you mean by Assuming that the communication is encrypted ? You mean you use certificates, STunnel, SSL ... something like that ? the tunnel of communication is secured with SSL ? – user45139 Jul 25 '14 at 6:45
  • 5
    what sites are these? i've never seen this for login but i've seen it for signup. another potential flaw in this system is that you cant rate limit incorrect passwords the same way as a normal login – DHall Jul 25 '14 at 13:33
  • 2
    Most of these systems I've seen (as a web developer) are implemented entirely on the client-side as Javascript. By not sending the password until you submit the form, many attacks are mitigated. The script could send each partial password off somewhere, but this kind of validation is easy enough to do in the browser that many (most?) do so. – ssube Jul 25 '14 at 14:27
  • 5
    Are you sure it is checking for password correctness, and not merely for length? – jjanes Jul 25 '14 at 15:34
  • 1
    You can use fiddler to determine if its actually hitting the server with every keypress. And I assume it does pose a security risk since it makes bruteforce much easier (essentially xn instead of x^n attempts required) – Akash Jul 25 '14 at 18:44
22

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:

  1. AES
  2. RC4
  3. 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).

  1. 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.

  2. 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.)

  3. 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.

| improve this answer | |
  • 1
    Nice answer. Take a look at this blog.cryptographyengineering.com/2013/12/… GOD BLESS AMERICA – David Barker Jul 25 '14 at 7:29
  • Actually this setup triggers traffic that looks like what broke SSLv1 last year for all ciphers except RC4 (BEAST attack). This is a fixable problem, evidenced as TLS 1.2 was not affected. – Joshua Jul 25 '14 at 16:19
  • Yes, BEAST is similar to CRIME, and fits into risk category 1 above. BEAST required many thousands of requests, which you don't have here. – David Jul 25 '14 at 18:53
  • This would also make an online brute-force attack more likely to succeed. – user49075 Jul 31 '14 at 0:53
  • More exactly, BEAST required many partly-chosen messages. And it applied to SSLv3 and TLSv1; TLSv1.1 and v1.2 (both) had the random-IV fix, and SSLv1 and v2 were long dead. – dave_thompson_085 Jul 31 '14 at 9:51
7

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.

| improve this answer | |
5

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 ✓ ?

| improve this answer | |
  • The form I'm referring to here is for login, not registration. I'll make a note of that in the question, as it seems to be a bit unclear. – sapi Jul 26 '14 at 0:44
  • 2
    Yes, my answer was for a login, not registration. Another example I've seen is where you cannot click the "login" button to send credentials until the password format is valid. Perhaps you can give an example of one of the sites? – Jacob Jul 26 '14 at 1:11
0

I can see a sever problem here: You can attempt brute force cracking while the server does the heavy lifting. In the case of a sufficiently powerful server, the attacker has a good chance of success at little or no (client side) computing cost. If the server is too weak, it opens up a nice channel for a denial of service attack.

Last time I checked, it was considered good practice to introduce a small (random) sleep before returning the results; checking the password for each character typed seems to work backward from this.

| improve this answer | |
  • This isn't really any weaker than a "submit the login form" system: an online brute force attack takes about as long in both cases. – Mark Jul 25 '14 at 19:46
  • 2
    @Mark: They're only equally fast if neither system implements a time penalty for incorrect guesses. A proper login form can afford to do this, but a live checker can't: each incomplete password is an incorrect guess, so adding a time delay would defeat the purpose of live checking. – The Spooniest Jul 25 '14 at 20:31
  • 1
    @TheSpooniest: Suppose that before a request could be submitted the page had to have requested and received a one-time use token; submitting a rejected password would return a new one-time-use token which would not have a time penalty, but could only be used to check passwords which led off with the given token. Not saying a UI should provide any indication of whether a password is correct before "enter" is pushed, but I would think such a design could guard against brute-force attacks with increasing time penalties. – supercat Jul 26 '14 at 0:20
0

I don't see any reason for the incomplete password to ever be sent to the server - the client knows the rules of the password (i.e. 8 chars, must contain number, etc.) and can validate it and display the status to the user prior to sending any request

| improve this answer | |
  • How can a client know if the password is correct before attempting authentication? That would require the client to have the hash to check against. – sapi Jul 26 '14 at 0:45
  • Because the password rules aren't secret, and checking against them can be done client side - i.e. if it is checked against the known rules, then it is assumed to be valid, but not necessarily correct – user2813274 Jul 27 '14 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.