GNOME Bugzilla – Bug 557382
WPA password changes into hash, not properly stored
Last modified: 2009-05-12 17:52:54 UTC
Please describe the problem: With nm-applet 0.7.0 from ubuntu intrepid, 64 bit, I have problems connecting to my FON router. After I connected successfully (multiple tries are needed most of the time) the stored password in the network connections editor is changed into a large hash. Steps to reproduce: 1. Connect to the private part of a FON router (MyPlace) using the correct password (mine is gEPqkcrRDF6zvq0j ) 2. After connecting, open the connection editor and allow it access to the keyring 3. Choose show password below "WPA & WPA2 Personal" in the Wireless Security tab of the "Editing Auto MyPlace" window. Actual results: The revealed password is "b5bdff92f8e32e44043c57fcc3957776cc49a4f57c822efd50929de0637ff78b" instead of the correct password given earlier. This password is also shown when a connection fails and you get a retry of the password. Expected results: I would expect to see the correct password "gEPqkcrRDF6zvq0j". Does this happen every time? Yes Other information: I'm running Ubuntu intrepid (un-released development version) on 64bit with Network Manager applet 0.7.0. This comes from the following packages: network-manager-gnome 0.7~~svn20081020t000444-0ubuntu1 The router is a FON.com router and my hardware uses the iwlagn driver.
This was reported on launchpad at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/239970 it is present with NetworkManager Applet 0.7.0 "The passwords shown in nm-edit are not the ones you enter when you connect. Instead they seem to be long lists of hex values. (6e8f1eef9e2444133be44a5f49ec65d2b69303067e4baac8e4f03b67fb7fe430) nm-edit should display the key you actually typed in when you connected to the network."
I just found out this extra piece of information, which makes the hex value appropriate. You can generate it with wpa_passphrase. My case revealed: network={ ssid="MyPlace" #psk="gEPqkcrRDF6zvq0j" psk=b5bdff92f8e32e44043c57fcc3957776cc49a4f57c822efd50929de0637ff78b } So, network manager is obviously showing the second psk to the user and not the commented out version (which would not be as confusing). For some reason it doesn't seem to do this a second time, so if you leave the long hex in the textfield it won't re-passphrase it and come up with another hash. So the bug may just only be confusing to the user and not bad for the actual authentication. (which would also mean that my connection problems probably stem from something different (I'm suspicious of the quality of iwlagn at the moment))
Ah I see I did not read your original report very well. I have not had connection problems nor was that reported downstream on the launchpad bug. Question: how were you able to convert the hex back to the original passphrase? This would be a good workaround until the bug is fixed. I tried entering 'wpa_passphrase' followed by the hex number in a terminal it just says '# reading passphrase from stdin' and never stops.
You cannot get the original password from the hash, that is a misunderstanding. wpa_passphrase will tell you which WPA key to use given an SSID and your passphrase. So, for example, my router has SSID MyPlace, the password is gEPqkcrRDF6zvq0j. Running: wpa_passphrase MyPlace gEPqkcrRDF6zvq0j Will output: network={ ssid="MyPlace" #psk="gEPqkcrRDF6zvq0j" psk=b5bdff92f8e32e44043c57fcc3957776cc49a4f57c822efd50929de0637ff78b } (also see "man wpa_passphrase") Please post any other questions on program use on forums, because they have no place in bugreports. Thank you for reporting.
The same bug has been reported in seahorse please see http://bugzilla.gnome.org/show_bug.cgi?id=558743
From the seahorse version of this bug ( http://bugzilla.gnome.org/show_bug.cgi?id=558743 ) "I think what's happening is for wireless networks you're entering an ASCII passphrase but NM is storing and using the hex equivalent. You should keep in mind that seahorse is not the store for passwords stored by various applications, that's gnome-keyring, but is only a viewer/editor. I think this is an issue with NM not keeping track of which format the network passphrases are stored in and then displaying the format it stores the passphrase in later. I'm closing this bug, but please reopen it if in the course of resolving bug 557382 you learn we're displaying something incorrectly." ~ Adam Shreiber To my knowledge this bug has not been filed against gnome-keyring I don't think it will be necessary to file one unless it appears NetworkManager is not the problem.
I confirm: I have the same bug. I use too a Fonera. But not at the first connexion. If I use a save passphrase on the system, I have this bug. But if I change the wap passphrase on the Fonera router and I use it on my PC, no bug at the first connexion. I hope it'll help.
*** Bug 565749 has been marked as a duplicate of this bug. ***
I have this problem too (wanted to transfer a password to a Vista machine). One argument for storing the passphrase instead of the key is that the key changes if you change the SSID of the router but the password doesn't change. Vista has an option to import network settings from a USB key. It would be great if NM could export the network settings to a USB key compatible with Vista (or import them).
+1 I am currently using wicd because of this issue. I would like to come back to Network-Manager, but being able to retrieved the wireless passwords *unhashed* is very important to me. I often need to read my wifi passwords to copy them to another mobile device/computer. This issue has been open so long (much before this bug notification) that I wonder if one day it will change. I found it around two years ago (and though it was a gnome-keyring issue, but I should have notified it, blame on me) and today I was just trying to find whether it was solved or not... It is a pity because Network-Manager is great, except for this issue. Carlos
(In reply to comment #10) > This issue has been open so long (much before this bug notification) that I > wonder if one day it will change. I found it around two years ago (and though > it was a gnome-keyring issue, but I should have notified it, blame on me) and > today I was just trying to find whether it was solved or not... Yes, it will get fixed, but it's not considered a blocker issue because the Hex key hash that the passphrase gets converted into *is* the valid WPA key (its what actually gets sent to the driver) and thus it shouldn't be a functional issue, just cosmetic and confusing.
Of course, as you say, it is not a functional issue for wifi connection but i think it is a functional issue for the user. I believe that the main problem is that many people consider their connection manager as a tool to get connected to the wifi spots *and* to store their wifi passwords. This is consistent with the fact that network-manager stores the passwords in the gnome keyring (avoiding to re-invent the wheel), but, in my opinion, it is inconsistent with the way it stores them (i.e. hashed through wpa_passphrase). In any case, thank you for your rapid reply, and for the job you do for the community. Many of us would be stuck with the old linux systems of the eighties if it weren't for the projects people like you develop!! Carlos
NM: f3c9887472ef6d773aeabd0bb7fcf102cf725398 (0.7.x) 07cc26d5fc3df0ed47b4bb993ce9a0d4f0008876 (master) applet: 1009da18d3e8fb9a86a01b43d27bd5cfc3a46336 (0.7.x) d9c45bfcf9db522c1724097341016cfca4e2fb78 (master)
A comment from 565749: Comment #6 from Dan Williams (NetworkManager developer, points: 18) 2009-05-12 17:47 UTC [reply] I think you misunderstand... both that bug and your bug are about storing exactly what the user typed in, and present that back to the user, instead of the long hex key. To be clear: the fix for 557382 makes the applet store what the user typed in, *not* the hashed hex key, and will present back to the user exactly what they typed in both the connection editor and the applet.