Wifi auto-connection asks for keyring password

Reported by Sadi78 on 2009-06-17
70
This bug affects 8 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Undecided
Unassigned
network-manager-applet (Ubuntu)
Undecided
Unassigned

Bug Description

When the computer boots, it asks for the keyring password in order to automatically connect to a wifi network. This way, it is really dificult to set the system to autologin and automatically connect to the wifi network, start an internet application (mostly p2p, could be any server) and have it running.

It would be nice to be able to connect to a wifi network without this prompt. Maybe the solution is to chose not to ask this specific question ever again (yes, windows-style), or to store some user-specified passwords in a publicly accesible keyring.

I think this behaviour could be related to bug #137247 (libpam-keyring broken on autologins):
https://bugs.edge.launchpad.net/bugs/1372479

Sadi78 (sadi78) on 2009-06-17
tags: added: network
removed: networking
description: updated
summary: - wifi connection asks for keyring password
+ Wifi auto-connection asks for keyring password
Sadi78 (sadi78) on 2009-06-17
description: updated
Ivanka Majic (ivanka) on 2009-06-17
Changed in hundredpapercuts:
status: New → Triaged
Martin Pitt (pitti) wrote :

FWIW, this is not a papercut, but requires some careful planning and upstream work. This doesn't happen if you log in through gdm normally, since then the keyring will be unlocked with your passphrase. If you use autologin, there are just two options:

 - asking for your passphrase to unlock the keyring
 - storing all your passwords unencrypted on your hard disk

I don't particularly like the second option, since the keyring also stores email/ICQ/etc. passwords, all your web passwords if you use epiphany, ssh passphrases, etc. We shouldn't just silently keep an unencrypted keyring and hide the potential vulnerability of this to the user.

What we could theoretically do is to not use gnome-keyring in network-manager-applet if it is locked, and instead store the plaintext WPA/WEP passphrase in network-manager itself. I'm less concerned about Wifi passwords than for SSH/web/email passwords; we need to treat those with care!

Martin Pitt (pitti) wrote :

Subscribed Alex and Seb to get their input as well.

Evan Dandrea (ev) wrote :

This was discussed in a thread on ubuntu-devel back in March:
https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027872.html

Martin Albisetti (beuno) wrote :

The desktop team has told us that this is complex to fix, thus invalidating it as a papercut.

Changed in hundredpapercuts:
status: Triaged → Invalid
Martin Pitt (pitti) wrote :

Adding n-m task, since it would still be nice to find a solution for this, or at least discuss it. Alex, would this be feasible?

Martin Pitt (pitti) wrote :

Marking as ayatana target as per David's request

affects: hundredpapercuts → ayatana
Changed in ayatana:
status: Invalid → New

Just to add some more information to this, if you edit the Wireless Connection you're using and check the "Available to all users" box at the bottom, the network will connect automatically when booting. You still might get asked to unlock your keyring for other applications trying to access it (like Gnome-Do or something else), but the network should connect in the background. Good choice for a papercut, btw. This is an annoyance.

Sadi78 (sadi78) wrote :

I thought of this as a papercut, even though I knew the solution is not easy.

I think that the best solution would be to create two keyrings, one private and one public. Of course, the user password is needed to write in both of them, but it is only needed to read the private one.

Then, an application in System->Preferences (can't remember if it's called exactly this way since I use the Spanish version) would allow the user to choose which passwords stay in the private keyring (the default behaviour) and which ones go to the public one. There's already a program there called "Encryption and keyrings" (or something similar, sorry again), and that would be a good candidate to add this functionality in another tab.

The network manager could ask, if the user chooses to store the wifi key, whether to make it public or private as well; but in less technical terms.

Sadi78 (sadi78) wrote :

Ok, I followed Jonathan's instructions and it works like charm. The problem is people doesn't know that making a wireless connection "Available to all users" means "No need to enter the keyring password".

What about changing the message in the checkbox for a two-line "Available to all users / (No need to enter the keyring password)"? And, of course, asking for this at the same time the n-m asks whether to store the password or not.

Jarko P. (jarko) wrote :

I'm not sure how this system works but as far as I understand, Network Manager asks for wireless password in Gnome Keyring. Gnome Keyring asks user to enter his/her keyring password and then grants or denies its access from keyring depending if the password was valid or not (or user simply denies access).

Would it be possible to modify/develop Gnome keyring to support checksums (or some kind of signatures?) as authentication method. ie. NM asks for permission to read password from Gnome Keyring. First time G. Keyring asks 'NM wants to access Gnome keyring. Enter your password to grant access.' User simply enters his/her password and THEN makes the choice if he/she wants to give NM a permission to auth on its own (by signature or checksum). If user ticks that box, keyring adds this software (its checksum) to the 'trusted' list.

This is just plain brainstorming, because I don't personally have much of an experience in programming.

That's not how it works. The main purpose of the keyring is to actually encrypt the different passwords using a master password, which makes it impossible to retrieve the passwords without you entering the right key. So the whole problem is: how can we give users the choice not to encrypt their WiFi passwords when they are using autologin? Then the trusted list is already working.

Jarko P. (jarko) wrote :

Sorry, I forgot the main point in that system. Of course it encrypts all the passwords by that master password. Dumb me. Anyway, forget what I wrote earlier.

Sadi78 (sadi78) wrote :

This problem has an easy solution, as stated in a previous comment by Jonathan Blackhall. Checking the "Available to all users" box solves the problem. So, now the real problem is to make people understand that checking this box will disable our famous prompt.

I suggest to add a checkbox when first connecting to a wireless network, so that the user can choose whether to store the wifi password and autoconnect to the network (these already exist) and, if so, whether to make it publicly available. Moreover, I would change the "Available to all users" message in the connection manager with something like "Make this connection publicly available". Something that clearly states that no password will be need, for the wifi nor the keyring. "Available to all users", keyrings..., confusing language to a non-tech user.

There is another choice. To simply store the password outside the keyring when the user chooses to autoconnect to a network. A warning should be shown at that point, saying that this is going to make the wifi password readable to everyone, and asking the user if he's sure he wants to do that.

Sadi78 [2009-06-20 0:46 -0000]:
> I think that the best solution would be to create two keyrings, one
> private and one public.

I agree.
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Sebastien Bacher (seb128) wrote :

there is similar bugs about evolution asking for a keyring password, we could move the nm passwords to a non secure keyring but that's just delaying the issue

Sebastien Bacher (seb128) wrote :

there is similar bugs about evolution asking for a keyring password, we could move the nm passwords to a non secure keyring but that's just delaying the issue you could as well ask the user to use a non secure storage

Bryn Hughes (linux-nashira) wrote :

OS X does this by having multiple keychains - a "system" keychain that holds "common" items like WiFi passwords, and a "private" keychain that holds everything else.

One thing to be aware of with all of this however is support for corporate-style WPA connections where a username/password pair (and possibly even a certificate) are used rather than just a consumer-style password. In the corporate scenario the current behavior is "correct" - the username/password pair should only be unlocked by the user who's credentials are being used - we don't want Bob to be using Mary's credentials on the corporate wireless network!

Ignoring auto-login for the moment, another way to look at this is "WHY are users seeing that message?", the answer in many cases being the system password has been changed to be different from the Keychain password. Again there's two ways to handle this:

1. When the user changes their system password, ask if their keychain password should be changed as well. Probably difficult to implement for command line utils though like 'passwd' unless it can be plugged in to PAM somehow.

2. When the password prompt is being displayed immediately after login, display a message with some text like "You were prompted for this password as your Keychain password is currently different from your Login password. Would you like to change your Keychain password to match your Login password?"

Cam Cope (ccope) wrote :

Isn't there already a fix that makes the keychain use the login password?
http://ubuntuforums.org/showthread.php?t=1028324

Is there some security issue with that, or can it just be implemented by default?

As for renaming the "Available to All Users" box, how about "Always use saved encryption key" or "Do not prompt for password on connect"

Changed in ayatana:
status: New → Invalid
tags: added: ayatana
Deryck Hodge (deryck) on 2009-09-03
affects: dead-ayatana → hundredpapercuts
Vish (vish) wrote :

Won't Fix in papercuts , but is tagged "ayatana" to be overseen in Ayatana project

Changed in hundredpapercuts:
status: Invalid → Won't Fix
Kangarooo Jānis (kangarooo) wrote :

i also have the same bug for one computer witch is rarely turned on.
it has xubuntu 09.10 and i installed it 3months ago.
strange that to other xubuntu installations i dont have this bug. maybe i should make apport-collect ?

Kangaroo: See comment #7 above. You just have to mark the connection as "Available to all users".

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers