System Encryption Password set before setting keyboard locale

Bug #1047384 reported by Martin Meredith on 2012-09-07
322
This bug affects 56 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Medium
Unassigned
xubuntu-default-settings (Ubuntu)
Undecided
Unassigned

Bug Description

Ubuntu 12.10

When installing my system, I selected to encrypt access to my system. This prompted me to enter a password. I entered a password with a # symbol in it, however due to using an english keyboard, this would not have been correctly recorded as a #, but as a ' instead - leading it to refuse my password when booting.

I tested this both connected to and not connected to the internet.

It seems that at the point of entering the password during the installer, the keyboard layout was set to en_US. Therefore, when booting and having the locale as en_GB - it didn't correctly work.

I tried this with the @ symbol, which when entered was accepted on boot by hitting shift+2 (american combination)

I also tried this by entering a password with a £ sign (shift 3 on UK keyboard - which would be a # on a US keyboard)

When entering password on boot, entering the password with the # key rather than the £ key worked.

In summary - when entering password for encrypting system, keyboard is set as a US keyboard layout, which differs from that when booting to enter the password if it is changed in a later step.

Proposed solution: Move the keyboard selection / Locale Setup before any input boxes. (espescially those where you can't see the contents of them!)

<http://goo.gl/YwIcT>: "The “Keyboard layout” screen should appear immediately before whichever is the first keyboard-requiring step."

<https://goo.gl/lDfhcI>: "Whenever “Encrypt the new Ubuntu installation for security” is checked, the caption 'You’ll choose a security key in just a moment.' should be sensitive. 'Choose a security key' is a keyboard-requiring step, so that typing the security key works as expected."

It may save time to fix this at the same time as bug 871752.

Martin Meredith (mez) wrote :
Changed in ubiquity (Ubuntu):
status: New → Confirmed
importance: Undecided → High
importance: High → Medium
tags: added: needs-design
Dimitri John Ledkov (xnox) wrote :

Currently we try to ask partitioning questions as soon as possible such that we can do partitioning & installation in parallel with users fiddling with the webcam to take a perfect shot for their user profile and things like that.

Now with newly added cryptsetup, we need a pass-phrase to create a container to create the partitions and start installation. We ask user's keyboard layout after we already started installation and recorded passphrase in the LUKS slot.

Ideally we want to use correct layout for password, yet setup keyboard layout during installation

Option one:
- generate random encryption password
- start the install
- proceed to user setup
- ask for keyboard layout
- setup up the real passphrase slot
- optionally remove the random encryption passphrase
- possibly pre-seed other passphrases (e.g. company wide)
- in OEM mode allow to skip setting up the user passphrase and setup the random one as a keyfile in the initramfs, to allow users to set their own passphrase on first boot (there are some security implications with this)

Option two:
- if encryption was selected, move the keyboard layout step before setting up the passphrases

Option three:
- display the passphrase in clear text such that users are aware of this

Changed in ubiquity (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
Dimitri John Ledkov (xnox) wrote :

MPT:

Can you please think about this "keyboard" layout problem when setting up the encryption pass phrase?

Possibly a quick solution which can be implemented for Beta-2 and maybe a more extensive suggestion in the Design Spec for Rancid Raccoon.

Dimitri John Ledkov (xnox) wrote :

<slangasek> I like solution #1
<stgraber> xnox: going with a random key, then adding the real one and removing the random one sounds like a good idea

@mpt: at this point are you going to start saying that we should reuse login password as the full disk encryption password?

Matthew Paul Thomas (mpt) wrote :

In the current design, the "Encrypt the new Ubuntu installation for security" checkbox has the caption "You'll choose a security key in the next step.". Either way, that text would need to change.

Dmitrijs' option 1: "Installation type" > "Where are you?" > "Keyboard layout" > "Security key" > "Who are you?" > "Choose a picture"

Dmitrijs' option 2: "Installation type" > "Keyboard layout" > "Security key" > "Where are you?" > "Who are you?" > "Choose a picture"

Dmitrijs, are you saying that "possibly pre-seed other passphrases (e.g. company wide)" and "in OEM mode allow to skip setting up the user passphrase and setup the random one as a keyfile in the initramfs" are *reasons* to choose option 1? Or are they just things that would be easy to implement at the same time?

On 27 September 2012 11:58, Matthew Paul Thomas <email address hidden> wrote:
> In the current design, the "Encrypt the new Ubuntu installation for
> security" checkbox has the caption "You'll choose a security key in the
> next step.". Either way, that text would need to change.
>
> Dmitrijs' option 1: "Installation type" > "Where are you?" > "Keyboard
> layout" > "Security key" > "Who are you?" > "Choose a picture"
>

I prefer this one. Simply because after the "hard" installation type
question, I'd rather see an existing clickable map, then boring
keyboard layout :)

> Dmitrijs' option 2: "Installation type" > "Keyboard layout" > "Security
> key" > "Where are you?" > "Who are you?" > "Choose a picture"
>
> Dmitrijs, are you saying that "possibly pre-seed other passphrases (e.g.
> company wide)" and "in OEM mode allow to skip setting up the user
> passphrase and setup the random one as a keyfile in the initramfs" are
> *reasons* to choose option 1? Or are they just things that would be easy
> to implement at the same time?
>

These are simply the things that we will have to implement at one point.
The reasons behind implementation 1 is that it reduces the total
installation time, because it allows installation to progress in the
background while the user is setting the passphrase(s) up.

Regards,

Dmitrijs.

Benjamin Schmid (benbuntu) wrote :

I just stumbled over this issue: I have a german user and entered my passphrase containing the letter_"y". After reboot I was unable to start the system until (as an advanced user!) I was able to realize, that the password has been recording using a wrong keymap and I neet type "z" instead of "y".

What I'm really puzzled about: How can this issue have only the severity "Medium"?
In fact it renders potentially every quantal installation for any users who a) checks "encrypt my system" and b) does not have a US keyboard unusable?

scoopex (ms-ubuntu) wrote :

I also needed some time to find out that i only have to exchange the "z" and the "y".

Additional problems/suggestions:

- Just use the keyboard layout selected by the user to set the passphrase
- My Dell Latitude E6430 does not always show the password prompt for the disc enryption
  (hitting Control+F1 provided my the text-login)
- I also wondered why there is no graphical frontend to the crypsetup-tool in the standard distribution to change the disk encryption password(s)
  (non-commandline-users probably want to change the passphrase)

Changed in ubiquity (Ubuntu):
status: Confirmed → In Progress
James Bennet (6-launchpad) wrote :

On my system, I chose English UK keyboard. My account password was successfully set to something with a @ in it. However, when I supplied the same password to the boot encryption prompt, it read that key as a ", and vice versa (i.e. the boot encryption prompt was working on a US layout).

James Bennet (6-launchpad) wrote :

By the way, this can be triaged by doing the following on the next boot (if you could get access, but it was just not the key you expected i.e. in my case)

cryptsetup -y luksAddKey /dev/sda[x]
sudo cryptsetup luksRemoveKey /dev/sda[x] 0

Check with:

sudo cryptsetup luksDump /dev/sda5

Matthew Paul Thomas (mpt) wrote :

Specification updated. I've gone for option 2, because asking for the security key long after choosing encryption would seem out of context. The loss of speed is a worthwhile tradeoff to avoid this confusion.

Changed in ubiquity (Ubuntu):
status: In Progress → Triaged
assignee: Matthew Paul Thomas (mpt) → nobody
description: updated
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1047384

tags: added: iso-testing
Benjamin Schmid (benbuntu) wrote :

Unfortunately this issue is still present in the 13.04 Beta. As nearly every of the 249 countries _except_ US, IN, CA, AU, HK, NZ, ZA, MY, SG,PH uses a non US keyboard layout, this issue affects in my opinion a very large user base.

Proposal: As temporary interims workaround provide a least a text hint about the US keymap in the dialog where the user enters his volume password?

Dimitri John Ledkov (xnox) wrote :

Yes, we have a keyboard bug at every step of the installation:
https://wiki.ubuntu.com/Ubiquity/KeyboardBug

I was considering to "unhide" the password (e.g. [password| ] instead of [********| ] )

Benjamin Schmid (benbuntu) wrote :

> I was considering to "unhide" the password (e.g. [password| ] instead of [********| ] )
Perfect solution: +1
Even Bruce Schneier thinks password masking is overused: https://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html

Fabio Marconi (fabiomarconi) wrote :

Yes, but the problem still that I don't know English keymap when installing in others languages, so I cannot insert my desired password easily
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

The password works in the text consoles (Ctrl - Alt - F1 oder Ctrl - Alt - F2 ...). That means, in the text consoles is the correct keyboard layout activated. Only the graphical login worked always with US keyboard layout. I tried also XDM as graphical login screen, but it was still the US keyboard layout. I tried an other distribution (Linux Mint Debian Edition) --> same bug.

Maybe this bug relates to
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/990214

This bug became a bug for the lightdm-gtk-greeter package, but I thats this is wrong (XDM). I also think it's not a problem of the install process (console-Login + other distribution). Maybe it is a problem of the X-Server.

description: updated

The same error with 13.04

Workaround: Boot the Live CD to try Ubuntu, then configure the keyboard layout in Settings, then start the installer from the live CD.

Unfortunatly, this bug still exists in 13.10. If you think of the fact that the normal user doesn’t even know how to change the keyphrase even IF he somehow managed to log in one time, this is a bug of HIGH importance.

For every normal user that hasn’t a US-QWERTY-Layout, his first impression of Ubuntu will be a system he is logged out of. That’s a shame I think. So for 14.04 LTS, this should be fixed.

Maybe a workaround:

Check the current settings:
> gsettings get org.gnome.libgnomekbd.keyboard layouts

Overwrite the setting (replace 'fr' with your local key; 'de' is german for example)
> gsettings set org.gnome.libgnomekbd.keyboard layouts "['us\taltgr-intl', 'fr']"

Source:
http://askubuntu.com/questions/328952/i-cannot-change-the-login-managers-keyboard-layout

Does it work for you?

"If you think of the fact that the normal user doesn’t even know how to change the keyphrase even IF he somehow managed to log in one time, this is a bug of HIGH importance."
I deeply agree to that statement.

Lars J. Nielsen (ebidk) wrote :

James Bennet (#10):
"By the way, this can be triaged by doing the following on the next boot (if you could get access, but it was just not the key you expected i.e. in my case)

cryptsetup -y luksAddKey /dev/sda[x]
sudo cryptsetup luksRemoveKey /dev/sda[x] 0

Check with:

sudo cryptsetup luksDump /dev/sda5"

How is this supposed to be read?
Do I replace [x] with a number and if so, which one? My fstab doesn't list drives like that.

I'll echo the others in asking how this is only medium importance when it is this annoying to fix for users and has been in several releases (I'm on 13.10 desktop). And the arguments about it being faster to install when you can do some of the work in the background while the user fills in things is not a good one when for many of the security conscious users it means another reinstallation or more to make it work, maybe even resulting in some giving up enabling the feature or finding another distribution instead. Ubuntu is supposed to be one of the easy distributions, user confusing errors like this one are not acceptable for more than one release, if even that.

I'm tired of reinstalling because I forget about this (twice now), and because of silly things like enabling encryption of the home directory and then wanting to change user name (not just the displayed name but all the uses of the username) and it being easier to reinstall because the GUI tool doesn't do all that and there is no good documentation on how to do it manually for encrypted home directories.

itzeme (launchacc) wrote :

This is still a issue in Ubuntu 14.04, causing a lot of trouble for anyone with a non english keyboardlayout.

itzeme (launchacc) wrote :

Ubuntu (gnome) 14.04 beta1 is still affected by this bug, making full disk encryption unuseable for everyone except us keyboard users.

(Debian does not seem to have this issue. What do they do different?)

Bruno (bruno-42) wrote :

The "Encrypt the new Ubuntu installation for security" will use the wrong keyboard if you
1) boot from ISO
2) wait (do not touch the small icon)
3) it autostarts the GUI installer (using En as Language and probably US as keyboard)
4) Enable "Encrypt the new Ubuntu installation for security"
5) next step is to provide the security key
HERE is the bug:
In the next steps the keyboard is autodetected and changed if you do not have a US keyboard
Until this step I never saw what I typed => i'm not aware of the US keyboard setting

=> type rtz as key
(since US keyboard this actually rty (if a qwertz keyboard is used)

6) press install now
=> "Where are you" => autodetected location => Zurich
Press continue
7) now Switzerland Keyboard Layout is detected an set up from now on.

=> security key (with US keyboard) was typed as rtz but rty was used.
But now since Swiss Keyboard is used => one would have to type rty instead of rtz.
How would a normal user know?

I think step 4 should be AFTER step 7. This way the correct keyboard would have been used.
After Mr. Snowden showed up and there is an "NSA-awareness" more users will use this option:
"Encrypt the new Ubuntu installation for security"
But non US keyboard users will run into this bug, if they use Z, Y, umlauts or special chars...

Thx for ubuntu :-)

Bruno (bruno-42) wrote :

If one uses the small icon @ISO boot time and does the keyboard set up (F2 and F3) then all goes well

1) boot from ISO
2) **** USER interaction: F2 / F3 => keyboard layout set up for installer
3) start GUI installer (using text menu)
4) Enable "Encrypt the new Ubuntu installation for security"
5) provide the security key
(I gave rtz using swiss german keyboard)
6) press install now
=> "Where are you" => autodetected location => Zurich
...

After reboot I give rtz as security key => all OK

So one solution would be to force the users to use the F2 / F3 setup during ISO boot time.
Currently there is not much time to stop the autostart (~3 sec).
And why would a new user even try to stop the autostart (when the first action in the GUI is to select the language)?

Better would be to detect the keyboard layout PRIOR to
Enable "Encrypt the new Ubuntu installation for security"

Can't understand, that this hasn't been fixed yet, especially with the LTS version. This bug will cause a lot of international users to drop out out at the encrypted installation, since there is no obvious feedback for the error available.

no longer affects: ubiquity (Ubuntu Trusty)

The bug is still present in Ubuntu 14.10 / Utopic. It is very hard for international users (other keyboard layout) to set a password as many keys are mapped at a different location.

The intended "Ubuntu installation process" was correct.

"The “Keyboard layout” screen should appear immediately before whichever is the first keyboard-requiring step."
https://docs.google.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit?pli=1#

by Christina Li http://design.canonical.com/author/christina-li/

Related: Timezone select before keyboard select
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/630990

tags: added: installation keyboard keymap locale utopic
tags: added: trusty
tags: added: password

I can confirm this workaround:
1. after the first boot choose "Try Ubuntu without installing".
2. look for the keyboard settings in the application menu and choose your keymap.
3. start installing Ubuntu from via the desktop icon.

_dan_ (dan-void) wrote :

There are many workarounds, that's not the issue here.

description: updated
description: updated
jtlb (jt-lb) wrote :

Let's take a completely different view angle:
 - the user does not see what he types when installing: it's hidden
 - the user does not see what he types when booting: it's hidden too
 - the disk has a *very* low probability to move to another desktop, especially one with a different keyboard

With this in mind, an approach could be:
 - temporarily force keyboard layout to US on initial creation
 - temporarily force keyboard layout to US when opening the disk

Florian (burna1) wrote :

Keep it simple - choose Option 2 from comment #2 - that is the only logical solution.

Option two:
- if encryption was selected, move the keyboard layout step before setting up the passphrases

Antoine Pitrou (pitrou) wrote :

This bug is really serious as it may force people to use a less strong password than desired.

FMaz (fmaz008) wrote :

pitrou:

No, the main concern is not that it will force people to use simpler passwords, but that people will install, without being aware of the layout issue, then on first boot be locked out, not understanding why, and having to re-install or re-format loosing all their data.

Which is what happened to me at first, and one of the reason why I completely stopped to use Linux (and it used to be my main OS for years)

N. W. (nw9165-3201) wrote :

Any update?

Kenrick Bingham (loxo) wrote :

Still present in Ubuntu 16.04.1.

Max Kristen (kristbaum) wrote :

Still present in Ubuntu 16.10. I want to suggest to move the "Choose Keyboard Layout"-step right after language selection.

Max Kristen (kristbaum) on 2017-01-10
tags: added: zesty
Stephen Hope (stevehope) on 2017-04-08
affects: ubiquity (Ubuntu) → xubuntu-default-settings
Changed in ubiquity (Ubuntu):
status: New → Confirmed
no longer affects: ubiquity (Ubuntu)
affects: xubuntu-default-settings → ubiquity
Colin Watson (cjwatson) on 2017-04-10
affects: ubiquity → ubiquity (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xubuntu-default-settings (Ubuntu):
status: New → Confirmed
To post a comment you must log in.