Today I went to log into my American Express Serve account at https://secure.serve.com/ and accidentally discovered what appears to be a huge hole in their login process.

Here are the steps involved:

  1. Enter a valid email Serve email address into the Email box.
  2. Type at least one character in the Password box.
  3. Tab out of the Password box.
  4. "Please enter a valid password." is now shown in red below the password box.
  5. Go back to the Password box and start typing characters.
  6. With each character typed, the password is checked. Once the password is valid, the red text goes away, indicating a valid password.

Now, once the Log In button is hit, the user is asked security questions. This seems to mitigate the problem, but the password is already known at this point!


Comments in this question are correct: The password isn't being checked. What is being checked is whether the characters entered match the password requirements. This does seem to be a reasonable behavior.

  • So you're saying you still need to bruteforce the account? May 17, 2015 at 18:04
  • That page is weird: It does not seem to send a network request when you submit - so it looks like it's checking the password client-side, i.e. offline. That would likely be horriby insecure...
    – sleske
    May 17, 2015 at 19:51
  • 1
    Are you sure it isn't just checking length? If you enter the wrong character in the 2nd character you type, does it behave differently than if you enter the correct character?
    – gowenfawr
    May 17, 2015 at 20:02
  • 9
    It just checking (in the browser) that the password you entered meets the rules - at least 8 characters long, at least 1 number, at least 1 lowercase, at least 1 uppercase and no symbols. It's not checking that the password is the correct one for the username until you press the 'Log In' button. It then connects to the server to validate.
    – Ian Cook
    May 17, 2015 at 21:10
  • @IanCook, you are correct. I feel much better now. May 18, 2015 at 0:15

1 Answer 1


start typing characters., Once the password is valid, the red text goes away, indicating a valid password.

This kind of behavior doesn't necessarily violate PCI DSS requirements.

If the site works the way you describe, it's not very good from a security point of view because it makes brute force attacks more difficult to detect -- but that doesn't make it non-compliant.

The reason it's not very good from a security perspective is that there is no difference from the system's point of view from a user typing a 10 character password to a user trying 10 different passwords, so any type of request throttling or account lockout would have to account for the "attempts" made while entering the password.

How can this be PCI DSS compliant?

Many of the PCI-DSS password requirements do not apply to customer logins - only to "non consumer users".

For example,

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.

does not apply to the "customer user":

Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

So even though this is not good security, there is nothing that prevents PCI compliance.

Standard disclaimer: I am not a QSA, and even if I was I am not your QSA, therefore my opinion would not affect yours (or anyone else's) compliance.


As Ian Cook notes, the site appears to be simply checking the password meets strength requirements, not the password itself. Therefore my answer above reflects the site behaviour as stated in the original question. If the site is only checking password strength, then the site will have no problem detecting and responding to any brute force attacks.

  • @d.w. The answer was based upon the statements in the original question, particularly item 6, not an analysis of the site itself. On Stackexchange.com, external links are subject to change so it is best to answer the question as stated. My points relating to whether a site behaving in this manner would affect its PCI compliance still stand. May 17, 2015 at 22:13
  • OK. In defense of this answer, the question does ask "How can this site be compliant?", and your answer does explain one way it could be compliant (even though in this case the correct answer might actually be "You've misunderstood how the site works, that's how it can be compliant."). So, you raise good points -- thank you.
    – D.W.
    May 17, 2015 at 22:17
  • I would be surprised if the system can't differentiate between a 10 character password and 10 different passwords. The former would logically be checked on the client side; the latter would need to be submitted to the remote server.
    – sapi
    May 18, 2015 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .