You could if the password verification is done very badly. Namely if the password verifier does all of the following:
- The password verifier stores the passwords in the clear (and not hashed as they should be)
- The password verifier compares the guess and the password directly (and not a hash of the guess and the password)
- The password verifier behaves differently depending on which character the password check fails on
- The password verifier doesn't limit the number of bad attempts
The first condition is the most important. If the implementer of a password verifier stores clear passwords, it's unlikely that they've gone to the trouble to implement a secure password comparison algorithm.
It's sad to say, but there are a surprisingly large number of Internet sites that store passwords in the clear. PlainTextOffenders.com is a (Tumblr) blog dedicated to "outing" such sites and contains many hundreds of such sites.
If a service stores passwords in the clear then it is likely that it is susceptible to a form of side channel attack called a "timing attack". If the password verifier checks one character at a time and returns a password failure message when it encounters the first non-matching character then you can guess one character at a time (starting from the first) and based on the timing of the failure message identify each character. Due to the inherent noisiness of Internet communication timing you would need to try each possibility more than once, but it still would be substantially faster than a simple butebrute force attack.