Version: 0.9 (using KDE 4.4.4) OS: Linux When I am in an area where the wireless is not stable, Once the wireless network becomes unavailable, an authorization dialog for WAP or other password pops up with the stored password. User can click on a box to see the existing password there and can modify it. This is an insecure practice. If the wireless becomes available, the password dialog does not go as it is a dialog and waiting for response. So when my wireless network is not good, There is no hope of reconnect. In other words, Knetworkmanager always needs to be attended to. I cannot give a download and leave the system on its own if the wireless is not stable. Related bug is https://bugs.kde.org/show_bug.cgi?id=225115 In short the password prompt is the problem, it should not show at all. After strength comes back, knetworkmanager should try to reconnect. Reproducible: Always Steps to Reproduce: 1 connect to wireless network 2 go a bit far where the signal is low, disconnection will occur 3 password prompt will be shown by knetworkmanager 4 come back to high strengh area Actual Results: result: the password prompt remains, does not reconnect. Expected Results: not show password prompt because it is rare that the password changes often. networkmanager should reconnect once wireless strength returns.
I can confirm with KDE 4.5.1 . I can also add that the same happens with 802.1X over wired connection. remove the cable, reattach and ask to connect. It will show the authorization dialog instead of reconnecting (even if the wallet is already open) and potentially expose my password. I think the problem is that the manager interprets any reconnection as a "wrong password" error (even if just lost the carrier). I don't know if it is possible to distinguish an authentication error or not by asking networkmanager. And in any case the old password should not be shown at all. If you want to see it you should go to the wallet.
This is a security and usability problem. Kindly vote to escalate it's priority.
*** This bug has been marked as a duplicate of bug 225115 ***