System Encryption Password set before setting keyboard locale

Bug #1047384 reported by Martin Meredith
382
This bug affects 70 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
High
Unassigned
Bionic
Fix Released
Critical
Unassigned
xubuntu-default-settings (Ubuntu)
Invalid
Undecided
Unassigned
Bionic
Invalid
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.

Related branches

Revision history for this message
Martin Meredith (mez) wrote :
Changed in ubiquity (Ubuntu):
status: New → Confirmed
importance: Undecided → High
importance: High → Medium
tags: added: needs-design
Revision history for this message
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)
Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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?

Revision history for this message
Dimitri John Ledkov (xnox) wrote : Re: [Bug 1047384] Re: System Encryption Password set before setting keyboard locale

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.

Revision history for this message
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?

Revision history for this message
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
Revision history for this message
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).

Revision history for this message
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

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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?

Revision history for this message
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 [********| ] )

Revision history for this message
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

Revision history for this message
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

Revision history for this message
Carsten Holzmüller (carsten-holzmueller-q) wrote :

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
Revision history for this message
István Ujj-Mészáros (styu007) wrote :

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.

Revision history for this message
Joshua Gleitze (joshua-gleitze) wrote :

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.

Revision history for this message
Carsten Holzmüller (carsten-holzmueller-q) wrote :

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.

Revision history for this message
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.

Revision history for this message
itzeme (launchacc) wrote :

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

Revision history for this message
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?)

Revision history for this message
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 :-)

Revision history for this message
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"

Revision history for this message
Rafael Gattringer (rafael.gattringer) wrote :

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)
Revision history for this message
Rafael Gattringer (rafael.gattringer) wrote :

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.

Revision history for this message
Rafael Gattringer (rafael.gattringer) wrote :

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/

Revision history for this message
Rafael Gattringer (rafael.gattringer) wrote :

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
Revision history for this message
Rafael Gattringer (rafael.gattringer) wrote :

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.

Revision history for this message
_dan_ (dan-void) wrote :

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

description: updated
description: updated
Revision history for this message
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

Revision history for this message
Florian (flfuchs) 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

Revision history for this message
Antoine Pitrou (pitrou) wrote :

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

Revision history for this message
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)

Revision history for this message
N. W. (nw9165-3201) wrote :

Any update?

Revision history for this message
Kenrick Bingham (loxo) wrote :

Still present in Ubuntu 16.04.1.

Revision history for this message
kristbaum (kristbaum) wrote :

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

kristbaum (kristbaum)
tags: added: zesty
Stephen Hope (stevehope)
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)
affects: ubiquity → ubiquity (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in xubuntu-default-settings (Ubuntu):
status: New → Confirmed
tags: added: artful xenial
Changed in ubiquity (Ubuntu):
importance: Medium → High
Revision history for this message
Kev Bowring (flocculant) wrote :

Not sure if this has mysteriously been fixed. But ...

Having to boot iso without splash in virt-manager currently and it appears that kbm map is set to UK for me when setting the encrypt password.

Revision history for this message
Kev Bowring (flocculant) wrote :

confirmed that behaviour elsewhere

Revision history for this message
Sébastien Deleuze (sdeleuze) wrote :

I just hit that bug while installing Ubuntu 17.10. It strongly impacts security of all non QWERTY users in the world, please fix it, you just have to put the keyboard layout selection screen at the beginning of the install process.

Will Cooke (willcooke)
tags: added: rls-bb-incoming
Steve Langasek (vorlon)
tags: removed: rls-bb-incoming
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

tags: added: id-59777adc5b653ed1d02a72c8
Revision history for this message
Thorsten Munsch (thorsten-munsch) wrote :

Still present in Ubuntu 17.10 desktop and netboot installer.

Don't know if this fixes for the desktop installer, but it did for the netboot: https://blog.hartwork.org/?p=1765

I saw the passphrase during disk setup so I was sure that it was correct German keyboard layout.

After installation the initrd's keyboard is in US layout while it asks for the passphrase.

Setting KEYMAP=Y in initramfs.conf + update-initramfs didn't help.

Glad I don't have to reinstall.

Revision history for this message
Thorsten Munsch (thorsten-munsch) wrote :

Installed my desktop with the xubuntu 17.10 mini.iso with bootkbd=de (German) parameter.

During installation the keymap is German which is correct. After a reboot the initrd's keymap is set to a qwerty layout instead of a qwertz which we use here.

Revision history for this message
theghost (theghost) wrote :

Beginning with 17.10 this is an issue. Before 17.10 you could workaround the issue by installing an encrypted luks in your locale by starting the live desktop and setting the correct keyboard BEFORE starting the installer.

This workaround does not work anymore since 17.10.
It's pretty sad that this is still an issue today...especially since the issue is known for years.

Afaik, the only distribution installers doing it right at the moment are Fedora's Anaconda and Antergos Cnchi.
Suse is currently working on a proper upstream fix for Systemd: http://bugzilla.suse.com/show_bug.cgi?id=1046436 so this issue will be fixed for OpenSuse in the next Leap version.
It's also an issue on Manjaro's Calamares.

Revision history for this message
PierreF (pierre-fersing) wrote :

I can confirm there is a bug in 17.10. It's probably another bug but has the same symptom: LUKS passphrase is prompted in qwerty and not with user defined keymap.

This is a "new" bug in 17.10, it worked in previous release.

A workaround is to copy /etc/console-setup/cached_UTF-8_del.kmap.gz (or similar) to /etc/console-setup/cached.kmap.gz and running update-initramfs -u

To reproduce this issue, do a *fresh* install of artful from server ISO (desktop not tested, maybe also affected), configure the keyboard layout to non-qwerty during install and use encrypted disk.
During boot, when prompted for luks passphrase the keyboard is in qwerty. If the user can enter its passphrase on a qwerty keyboard, the keymap is the correct one in the console. The issue seems to be only during initramfs.

I got the idea to copy cached.kmap.gz from Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619711

From my understanding this bug is a mismatch between the behavior of console-setup and initramfs-tools.
On Debian this seems fixed by hooks/keymap from initramfs-tools (not present in Ubuntu package).

On Ubuntu it seems still expected that /etc/console-setup/cached.kmap.gz is generated but it's no longer the case since artful:

$ debdiff console-setup_1.142ubuntu5.dsc console-setup_1.166ubuntu7.dsc:
[...]
- cached=/etc/console-setup/cached$VARIANT.kmap.gz
+ cached=/etc/console-setup/cached_${CHARMAP}_$backspace$VARIANT.kmap.gz
[...]

tags: removed: needs-design
Steve Langasek (vorlon)
Changed in ubiquity (Ubuntu Bionic):
status: Triaged → Fix Committed
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Moved keyboard step as early as possible.

Changed in ubiquity (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Theo Linkspfeifer (lastonestanding) wrote :

Is there a separate fix required for xubuntu-default-settings?

Changed in xubuntu-default-settings (Ubuntu):
status: Confirmed → Invalid
Changed in xubuntu-default-settings (Ubuntu Bionic):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.