linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Lehan <krellan@krellan.com>
To: Jouni Malinen <j@w1.fi>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Distinguishing wrong password from other failure to connect?
Date: Sat, 13 Nov 2010 18:47:23 -0800	[thread overview]
Message-ID: <4CDF4DBB.60909@krellan.com> (raw)
In-Reply-To: <20101113103457.GA5166@jm.kir.nu>

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

      reply	other threads:[~2010-11-14  2:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-12  7:25 Distinguishing wrong password from other failure to connect? Josh Lehan
2010-11-12 16:51 ` Johannes Berg
2010-11-12 17:21 ` Paul Stewart
2010-11-14  2:36   ` Josh Lehan
2010-11-13 10:34 ` Jouni Malinen
2010-11-14  2:47   ` Josh Lehan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CDF4DBB.60909@krellan.com \
    --to=krellan@krellan.com \
    --cc=j@w1.fi \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).