Distinguishing wrong password from other failure to connect?

Distinguishing wrong password from other failure to connect?

[Josh Lehan]

Hi.  Curious if there is a way to distinguish between the various
failure modes when failing to make an association to an AP.

In particular, I'd love to distinguish between these two states:

* User entered incorrect password

* User entered correct password, but the AP rejected them for some other
reason (perhaps signal was too weak, or the AP is using MAC address
filtering, or they couldn't negotiate a common encryption/authentication
protocol, or whatever).

Does the Linux wireless stack support a way for applications to gather
this information?  Are the "reason=0x00" bytes, sometimes displayed by
wpa_supplicant in the logs, standardized across all AP's?

This seems to be a common problem, because on many distributions, I see
NetworkManager constantly popping up the password entry box whenever an
association fails, when the user already knows the password is correct
(and in fact has entered it into the box already, as it's pre-filled in
the box, albeit starred out).

Thanks!

Josh

Re: Distinguishing wrong password from other failure to connect?

[Johannes Berg]

On Thu, 2010-11-11 at 23:25 -0800, Josh Lehan wrote:
> This seems to be a common problem, because on many distributions, I see
> NetworkManager constantly popping up the password entry box whenever an
> association fails, when the user already knows the password is correct
> (and in fact has entered it into the box already, as it's pre-filled in
> the box, albeit starred out).

It should only have that issue with WEP (which you shouldn't be using
anyway) and even then only when shared key auth is not available.
Otherwise, the supplicant should have enough info about the failure.

johannes

Re: Distinguishing wrong password from other failure to connect?

[Paul Stewart]

On Thu, Nov 11, 2010 at 11:25 PM, Josh Lehan <krellan@krellan.com> wrote:
> Hi.  Curious if there is a way to distinguish between the various
> failure modes when failing to make an association to an AP.
>
> In particular, I'd love to distinguish between these two states:
>
> * User entered incorrect password
>
> * User entered correct password, but the AP rejected them for some other
> reason (perhaps signal was too weak, or the AP is using MAC address
> filtering, or they couldn't negotiate a common encryption/authentication
> protocol, or whatever).
>
> Does the Linux wireless stack support a way for applications to gather
> this information?  Are the "reason=0x00" bytes, sometimes displayed by
> wpa_supplicant in the logs, standardized across all AP's?

The "reason=xx" codes are standardized by 802.11.  However when
reading such messages, one needs to be careful to note which party
sent that reason code.  There are times when the AP sends this
message, and other times where the station sends it as it departs.

> This seems to be a common problem, because on many distributions, I see
> NetworkManager constantly popping up the password entry box whenever an
> association fails, when the user already knows the password is correct
> (and in fact has entered it into the box already, as it's pre-filled in
> the box, albeit starred out).

It is a problem in general, but for the most part I believe the onus
lies with the supplicant, rather than the kernel to distinguish
between the various error cases.  It is the step between
wpa_supplciant and whatever connection manager which makes it tricky
to properly determine why a connection failed (or was lost) and relay
the correct information back to the user.  For example, in the
ChromeOS connection manager, if we note that wpa_supplicant fell out
of association while in the 4WAY_HANDSHAKE state, we assume that this
is due to a bad WPA passphrase, but in the (admittedly unlikely but
still statistically significant) case where we lose connectivity in
that state due to lower-level failure, we assume the same thing, and
tell the user their password is wrong.  Not a good experience.

Even in the WEP case, you can imagine the supplicant being proactive
in determining if the key is wrong by monitoring packet counts. In
this situation there may need to be some kernel help -- I'm not sure
where counters are kept of packets dropped due to failed WEP
decryption -- but if such a thing existed, wpa_supplicant could
presume the encryption key was incorrect after a period of time.

--
Paul

Re: Distinguishing wrong password from other failure to connect?

[Josh Lehan]

On 11/12/2010 09:21 AM, Paul Stewart wrote:
> The "reason=xx" codes are standardized by 802.11.  However when
> reading such messages, one needs to be careful to note which party
> sent that reason code.  There are times when the AP sends this
> message, and other times where the station sends it as it departs.

Thanks for the information.  Is there a guideline as to what messages
indicate wrong settings by the user (wrong password, etc.)?

Basically, I'm trying to know where to pin the blame: on the user's
wrong password, or on the network itself.

Josh

Re: Distinguishing wrong password from other failure to connect?

[Jouni Malinen]

On Thu, Nov 11, 2010 at 11:25:29PM -0800, Josh Lehan wrote:
> Hi.  Curious if there is a way to distinguish between the various
> failure modes when failing to make an association to an AP.

In some cases, yes, in many, not really in any reliable way.

> In particular, I'd love to distinguish between these two states:
> 
> * User entered incorrect password
> 
> * User entered correct password, but the AP rejected them for some other
> reason

That depends on which security mode you are using.. With
WPA/WPA2-Personal, there is no explicit indication that the connection
failed because of incorrect passphrase because the AP will silently drop
the message in which the wrong passphrase was used. In other words, the
protocol does not provide means for the AP to indicate that connection
failed because of incorrect key.

In WPA/WPA2-Enterprise, you may get an explicit error notification of
password failure with some EAP methods, but not all (they may have the
same lets-not-provide-any-more-info-to-attackers design for failure
cases).

> Does the Linux wireless stack support a way for applications to gather
> this information?  Are the "reason=0x00" bytes, sometimes displayed by
> wpa_supplicant in the logs, standardized across all AP's?

Well, the starting problem is that the protocol does not provide such
information (sometimes by design). The best you can do is to assume
things and hope that the most likely reason for an error was the cause
of the problem this time. For example, with WPA/WPA2-Personal, we may
assume that the passphrase was incorrect if we complete association
successfully, receive EAPOL-Key 1/4, send EAPOL-Key 2/4 and get it
acknowledged by the AP, but never see EAPOL-Key 3/4. This does not
guarantee that the reason for incorrect passphrase, but that is one of
the most likely reasons for this.

> This seems to be a common problem, because on many distributions, I see
> NetworkManager constantly popping up the password entry box whenever an
> association fails, when the user already knows the password is correct
> (and in fact has entered it into the box already, as it's pre-filled in
> the box, albeit starred out).

Asking for a passphrase again (and even worse, dropping the previously
stored passphrase based on this) is bad UI design in my opinion for many
of these cases. It should not really done unless we are pretty confident
that the reason was indeed in wrong passphrase. Especially the
forgetting of stored information should really never be done unless we
are very confident on this being caused by wrong passphrase (e.g., never
do that if we have successfully completed even one connection with
WPA/WPA2-Personal).

We have most of the needed information available in user space to allow
applications to do their best in figuring out what could have happened.
One small addition would be to make it easier to get TX status for
EAPOL-Key transmission (i.e., whether AP acknowledged a Data frame sent
by wpa_supplicant) into user space. hostapd can do this with a monitor
interface, and well, so could wpa_supplicant, but the simpler design of
just using normal data frame transmission routines does not provide that
indication back to the application. Still, this would not provide
completely reliable mechanism for determining whether incorrect
passphrase was used, but it would potentially allow limiting some of the
false positives from being reported in cases where 4-way handshake fails
due to AP not receiving frames from the station for some other reason.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Distinguishing wrong password from other failure to connect?

[Josh Lehan]

On 11/13/2010 02:34 AM, Jouni Malinen wrote:
> That depends on which security mode you are using.. With
> WPA/WPA2-Personal, there is no explicit indication that the connection
> failed because of incorrect passphrase because the AP will silently drop
> the message in which the wrong passphrase was used. In other words, the
> protocol does not provide means for the AP to indicate that connection
> failed because of incorrect key.

That makes sense, to do a silent drop, because of security (you don't
want to give positive feedback to a hacker that the password was
rejected, that would only make it faster for them to loop through a
dictionary of passwords).

It's a shame from a UI point of view, though.  I don't want to accuse my
user of entering the wrong password when in reality it was the network's
fault, and vice versa.

> Well, the starting problem is that the protocol does not provide such
> information (sometimes by design). The best you can do is to assume
> things and hope that the most likely reason for an error was the cause
> of the problem this time. For example, with WPA/WPA2-Personal, we may
> assume that the passphrase was incorrect if we complete association
> successfully, receive EAPOL-Key 1/4, send EAPOL-Key 2/4 and get it
> acknowledged by the AP, but never see EAPOL-Key 3/4. This does not
> guarantee that the reason for incorrect passphrase, but that is one of
> the most likely reasons for this.

Very clever idea.  It would be great to have visibility into the
authentication/EAPOL state machine, instead of just getting final states
like "ASSOCIATED".  Is this information available outside wpa_supplicant
in any standard way, or will I have to patch wpa_supplicant to find a
way to publish this information to my UI?

> Asking for a passphrase again (and even worse, dropping the previously
> stored passphrase based on this) is bad UI design in my opinion for many
> of these cases. It should not really done unless we are pretty confident
> that the reason was indeed in wrong passphrase. Especially the
> forgetting of stored information should really never be done unless we
> are very confident on this being caused by wrong passphrase (e.g., never
> do that if we have successfully completed even one connection with
> WPA/WPA2-Personal).

I'm glad I'm not the only one who is irritated by this design decision
of NetworkManager!  I keep wishing for a checkbox that says "I KNOW my
password is correct, please keep trying with it, and stop bugging me".
Oftentimes I'll walk my laptop out of range, then come back into range,
only to have my laptop fail to automatically connect because it's just
sitting there stuck at the NetworkManager password prompt.

Josh