After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 557382 - WPA password changes into hash, not properly stored
WPA password changes into hash, not properly stored
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: nm-applet
unspecified
Other All
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
: 565749 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-22 11:05 UTC by Bram Neijt
Modified: 2009-05-12 17:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bram Neijt 2008-10-22 11:05:33 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.
Comment 1 Elias K Gardner 2008-10-22 21:53:24 UTC
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."
Comment 2 Bram Neijt 2008-10-22 22:51:36 UTC
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))
Comment 3 Elias K Gardner 2008-10-22 23:29:43 UTC
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.
Comment 4 Bram Neijt 2008-10-23 07:13:33 UTC
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.
Comment 5 Elias K Gardner 2008-10-31 22:59:43 UTC
The same bug has been reported in seahorse please see http://bugzilla.gnome.org/show_bug.cgi?id=558743
Comment 6 Elias K Gardner 2008-11-16 19:39:47 UTC
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.
Comment 7 jah_6669 2009-02-21 21:40:24 UTC
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.
Comment 8 Dan Williams 2009-02-23 23:59:00 UTC
*** Bug 565749 has been marked as a duplicate of this bug. ***
Comment 9 Paul Wise 2009-02-24 04:55:39 UTC
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). 
Comment 10 Carlos Aguilar 2009-03-05 10:35:23 UTC
+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
Comment 11 Dan Williams 2009-03-05 11:36:28 UTC
(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.
Comment 12 Carlos Aguilar 2009-03-05 12:42:07 UTC
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
Comment 13 Dan Williams 2009-05-10 03:16:43 UTC
NM:

f3c9887472ef6d773aeabd0bb7fcf102cf725398 (0.7.x)
07cc26d5fc3df0ed47b4bb993ce9a0d4f0008876 (master)

applet:

1009da18d3e8fb9a86a01b43d27bd5cfc3a46336 (0.7.x)
d9c45bfcf9db522c1724097341016cfca4e2fb78 (master)
Comment 14 Dan Williams 2009-05-12 15:56:21 UTC
*** Bug 565749 has been marked as a duplicate of this bug. ***
Comment 15 Paul Wise 2009-05-12 17:52:54 UTC
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.