[opensuse-factory] Tumbleweed full disk encryption passphrase
Hello, after doing an installation with LVM and harddisk encryption enabled I need to enter the disk passphrase two times during boot. First when grub2 wants to read grub2 config and modules + initrd + kernel. And then a second time when kernel + initrd wants to mount the root filesystem. And to make it worse, I use special characters for my passphrase, which should be a good idea for a passphrase, and grub2 uses a different keyboard layout than the Linux installation. By that I need to type two different passphrases. To overcome this problem an unencrypted /boot could be used, but that is not the installation default. I could also add a second passphrase that uses a translated keyboard layout, but that is not very handy when I want to change the passphrase from time to time. It should be sufficient to type the passphrase only in grub2. After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured? The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu). Also some Arch Linux instructions [3] for grub, but not explicitly for grub2. What is the "opensuse tumbleweed way" of configuring this? Br, Frank [1] https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#With_a_keyfi... [2] https://superuser.com/questions/974833/change-the-keyboard-layout-of-grub-in... [3] https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Manual_configurati... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It should be sufficient to type the passphrase only in grub2. After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured?
For me the following works; you have to adapt the harddisk ID and device to your system. * grub2 options: boot from MBR GRUB_ENABLE_CRYPTODISK=y * Create file `/crypto_keyfile.bin'. dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin chmod 000 /crypto_keyfile.bin chmod -R g-rwx,o-rwx /boot * Add the following to `/etc/crypttab' (as a single line). cr_ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /dev/disk/by-id/ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /crypto_keyfile.bin * Create the file `/etc/dracut.conf.d/99-initcrypt.conf' with the following contents: install_items="/crypto_keyfile.bin" * Call »dracut --force« to activate the above setup. Werner
It should be sufficient to type the passphrase only in grub2. After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured?
For me the following works; [...]
I forgot to mention that this is for Leap 42.3 – hopefully, the setup is similar in Tumbleweed. Werner
19.05.2018 00:20, Werner LEMBERG пишет:
* Create the file `/etc/dracut.conf.d/99-initcrypt.conf' with the following contents:
install_items="/crypto_keyfile.bin"
This should be install_items+=" /crypto_keyfile.bin "
* Call
»dracut --force«
mkinitrd is still calling dracut with expicit parameters so it should be really mkinitrd to be on safe side. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.05.2018 um 23:20 schrieb Werner LEMBERG:
It should be sufficient to type the passphrase only in grub2. After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured?
For me the following works; you have to adapt the harddisk ID and device to your system.
* grub2 options:
boot from MBR GRUB_ENABLE_CRYPTODISK=y
* Create file `/crypto_keyfile.bin'.
dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin
chmod 000 /crypto_keyfile.bin chmod -R g-rwx,o-rwx /boot
* Add the following to `/etc/crypttab' (as a single line).
cr_ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /dev/disk/by-id/ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /crypto_keyfile.bin
* Create the file `/etc/dracut.conf.d/99-initcrypt.conf' with the following contents:
install_items="/crypto_keyfile.bin"
* Call
»dracut --force«
to activate the above setup.
That works also for Tumbleweed. With two modifications: - install_items+="/crypto_keyfile.bin" thanks to Andrei for the hint - "Add the following to `/etc/crypttab' (as a single line)." should be "append /crypto_keyfile.bin to the existing line for the roofs drive".
Werner
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
22.05.2018 21:02, Frank Kunz пишет:
Am 18.05.2018 um 23:20 schrieb Werner LEMBERG:
It should be sufficient to type the passphrase only in grub2. After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured?
For me the following works; you have to adapt the harddisk ID and device to your system.
* grub2 options:
boot from MBR GRUB_ENABLE_CRYPTODISK=y
* Create file `/crypto_keyfile.bin'.
dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin cryptsetup luksAddKey /dev/sda1 /crypto_keyfile.bin
chmod 000 /crypto_keyfile.bin chmod -R g-rwx,o-rwx /boot
* Add the following to `/etc/crypttab' (as a single line).
cr_ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /dev/disk/by-id/ata-YOUR_HARDDISK_IDENTIFIER-part1 \ /crypto_keyfile.bin
* Create the file `/etc/dracut.conf.d/99-initcrypt.conf' with the following contents:
install_items="/crypto_keyfile.bin"
* Call
»dracut --force«
to activate the above setup.
That works also for Tumbleweed. With two modifications: - install_items+="/crypto_keyfile.bin" thanks to Andrei for the hint
That's not what I said. Spaces around value *are* significant. Your line will work as long as this is the only install_items across all configuration files.
- "Add the following to `/etc/crypttab' (as a single line)." should be "append /crypto_keyfile.bin to the existing line for the roofs drive".
Werner
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 22.05.2018 um 20:06 schrieb Andrei Borzenkov:
That works also for Tumbleweed. With two modifications: - install_items+="/crypto_keyfile.bin" thanks to Andrei for the hint
That's not what I said. Spaces around value *are* significant. Your line will work as long as this is the only install_items across all configuration files.
Yes, that was my copy/paste fault for the mail list answer. Br, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.05.2018 um 00:35 schrieb Adam Mizerski:
W dniu 18.05.2018 o 23:20, Werner LEMBERG pisze:
For me the following works; you have to adapt the harddisk ID and device to your system.
Thanks! I'd love to see that written down on our wiki.
It was already there: https://en.opensuse.org/SDB:Encrypted_root_file_system Unfortunately duckduckgo did not find it at my first research, but searching directly in SDB I found it. I added some hints about initrd protection and locale. With that it contains the content of this thread I think. Br, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 18 May 2018 23:00:41 CEST Frank Kunz wrote:
[…] It should be sufficient to type the passphrase only in grub2.
Yes, it should be. Our automatic openQA tests also show this limitation in https://openqa.opensuse.org/tests/678582#step/grub_test/2 referencing a feature request "Provide kernel interface to pass LUKS password from bootloader" - but it is just this, a "feature request".
After some research I found some Arch Linux specific instruction [1]. But this uses an Arch specific initrd hook to open the encrypted fs by reading a passphrase from a file included in the initrd. I haven't found an equivalent hook in the tumbleweed dracut config. Would this setup also be a possible solution for tumbleweed? How could it be configured?
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu). Also some Arch Linux instructions [3] for grub, but not explicitly for grub2. What is the "opensuse tumbleweed way" of configuring this?
All this I do not know. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2018 12:03 AM, Oliver Kurz wrote:
On Friday, 18 May 2018 23:00:41 CEST Frank Kunz wrote:
[…] It should be sufficient to type the passphrase only in grub2.
Yes, it should be. Our automatic openQA tests also show this limitation in https://openqa.opensuse.org/tests/678582#step/grub_test/2 referencing a feature request "Provide kernel interface to pass LUKS password from bootloader" - but it is just this, a "feature request".
Yes. The YaST team got the clear requirement for SLE15 / Leap15 (and TW as a consequence, since the code is shared) of proposing a separate /boot only in scenarios in which it was absolutely indispensable to boot. Avoiding a separate /boot if possible even if encryption was involved. I assume that was requested under the assumption that the feature mentioned by Oliver would be ready on time for the Leap15 release time, which finally didn't happen. :-( Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Is it possible to "fix" this request by move /boot partition outside lvm? Or should I reinstall my system? Or even better if I hang on with my setup will an update require me to type my password just once or these feature will not be available in the next future? Sorry for all these questions but I don't want to type password three times every boot ( twice for grub, I guess because double HDD and once for booting system) so I'm deciding if reinstall system or if can be fixed. Thanks 19 mag 2018, 08:26 da ancor@suse.de:
On 05/19/2018 12:03 AM, Oliver Kurz wrote:
On Friday, 18 May 2018 23:00:41 CEST Frank Kunz wrote:
[…] It should be sufficient to type the passphrase only in grub2.
Yes, it should be. Our automatic openQA tests also show this limitation in https://openqa.opensuse.org/tests/678582#step/grub_test/2 https://openqa.opensuse.org/tests/678582#step/grub_test/2 referencing a feature request "Provide kernel interface to pass LUKS password from bootloader" - but it is just this, a "feature request".
Yes. The YaST team got the clear requirement for SLE15 / Leap15 (and TW as a consequence, since the code is shared) of proposing a separate /boot only in scenarios in which it was absolutely indispensable to boot. Avoiding a separate /boot if possible even if encryption was involved.
I assume that was requested under the assumption that the feature mentioned by Oliver would be ready on time for the Leap15 release time, which finally didn't happen. :-(
Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: > opensuse-factory+unsubscribe@opensuse.org mailto:opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: > opensuse-factory+owner@opensuse.org mailto:opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On samedi, 19 mai 2018 08.42:07 h CEST francesco.vo@tutamail.com wrote:
Is it possible to "fix" this request by move /boot partition outside lvm? Or should I reinstall my system? Or even better if I hang on with my setup will an update require me to type my password just once or these feature will not be available in the next future? Sorry for all these questions but I don't want to type password three times every boot ( twice for grub, I guess because double HDD and once for booting system) so I'm deciding if reinstall system or if can be fixed. Thanks
I've been using luks and lvm since years, but last time I 've redone my TW setup I pre prepare my nvme drive to be fully encrypted and pub btrfs on top. The described feature by werner is working like a charm I've a binary key that is able to reopen the root once the pivot is done. I enter one time a password at boot time But yes non hidpi, non localized keyboard in grub2 is annoying. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2018 08:42 AM, francesco.vo@tutamail.com wrote:
Is it possible to "fix" this request by move /boot partition outside lvm? Or should I reinstall my system? Or even better if I hang on with my setup will an update require me to type my password just once or these feature will not be available in the next future? Sorry for all these questions but I don't want to type password three times every boot ( twice for grub, I guess because double HDD and once for booting system) so I'm deciding if reinstall system or if can be fixed. Thanks
Yes. If you move your /boot out of the LVM then you will save you the Grub ones and you will only be asked once for each PV (hopefully that means only once in total). Cheers.
19 mag 2018, 08:26 da ancor@suse.de:
On 05/19/2018 12:03 AM, Oliver Kurz wrote:
On Friday, 18 May 2018 23:00:41 CEST Frank Kunz wrote:
[…] It should be sufficient to type the passphrase only in grub2.
Yes, it should be. Our automatic openQA tests also show this limitation in https://openqa.opensuse.org/tests/678582#step/grub_test/2 https://openqa.opensuse.org/tests/678582#step/grub_test/2 referencing a feature request "Provide kernel interface to pass LUKS password from bootloader" - but it is just this, a "feature request".
Yes. The YaST team got the clear requirement for SLE15 / Leap15 (and TW as a consequence, since the code is shared) of proposing a separate /boot only in scenarios in which it was absolutely indispensable to boot. Avoiding a separate /boot if possible even if encryption was involved.
I assume that was requested under the assumption that the feature mentioned by Oliver would be ready on time for the Leap15 release time, which finally didn't happen. :-(
Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: > opensuse-factory+unsubscribe@opensuse.org mailto:opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: > opensuse-factory+owner@opensuse.org mailto:opensuse-factory+owner@opensuse.org
-- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
19.05.2018 00:00, Frank Kunz пишет:
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu).
grub2 supports custom keyboard maps only for USB keyboard (it has own driver for it). For legacy BIOS or EFI it is currently whatever character firmware returns. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.05.2018 um 06:46 schrieb Andrei Borzenkov:
19.05.2018 00:00, Frank Kunz пишет:
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu).
grub2 supports custom keyboard maps only for USB keyboard (it has own driver for it). For legacy BIOS or EFI it is currently whatever character firmware returns.
Unfortunately this seems not to work in grub2 early stage where it asks for the passphrase. The modules are loaded after that from the decrypted /boot disk. Br, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
22.05.2018 21:56, Frank Kunz пишет:
Am 19.05.2018 um 06:46 schrieb Andrei Borzenkov:
19.05.2018 00:00, Frank Kunz пишет:
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu).
grub2 supports custom keyboard maps only for USB keyboard (it has own driver for it). For legacy BIOS or EFI it is currently whatever character firmware returns.
Unfortunately this seems not to work in grub2 early stage
What is "this"?
where it asks for the passphrase. The modules are loaded after that from the decrypted /boot disk.
You always can include additional modules in core.img for testing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 22.05.2018 um 21:05 schrieb Andrei Borzenkov:
22.05.2018 21:56, Frank Kunz пишет:
Am 19.05.2018 um 06:46 schrieb Andrei Borzenkov:
19.05.2018 00:00, Frank Kunz пишет:
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu).
grub2 supports custom keyboard maps only for USB keyboard (it has own driver for it). For legacy BIOS or EFI it is currently whatever character firmware returns.
Unfortunately this seems not to work in grub2 early stage
What is "this"?
means using the usb_keyboard driver by modify /etc/default/grub by adding: GRUB_PRELOAD_MODULES="usb usb_keyboard ehci ohci uhci" GRUB_TERMINAL_INPUT="usb_keyboard" comment out GRUB_TERMINAL="gfxterm" (due to http://www.gnu.org/software/grub/manual/grub/grub.html) append to /etc/grub.d/40_custom: insmod keylayouts keymap /boot/grub2/keyb_de.gkb generate the keymap: grub2-kbdcomp -o /boot/grub2/keyb_de.gkb de then run update-bootloader reboot but the keyboard layout for the passphrase is still US. Br, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
22.05.2018 22:22, Frank Kunz пишет:
Am 22.05.2018 um 21:05 schrieb Andrei Borzenkov:
22.05.2018 21:56, Frank Kunz пишет:
Am 19.05.2018 um 06:46 schrieb Andrei Borzenkov:
19.05.2018 00:00, Frank Kunz пишет:
The other problem is the different keyboard layout. For this I found some older instruction [2] for grub to load a specific keyboard layout in early stage before access the disk, but it is stated that this is not possible for grub2 (links the opensuse113 docu).
grub2 supports custom keyboard maps only for USB keyboard (it has own driver for it). For legacy BIOS or EFI it is currently whatever character firmware returns.
Unfortunately this seems not to work in grub2 early stage
What is "this"?
means using the usb_keyboard driver by
modify /etc/default/grub by adding: GRUB_PRELOAD_MODULES="usb usb_keyboard ehci ohci uhci" GRUB_TERMINAL_INPUT="usb_keyboard"
comment out GRUB_TERMINAL="gfxterm" (due to http://www.gnu.org/software/grub/manual/grub/grub.html)
append to /etc/grub.d/40_custom: insmod keylayouts keymap /boot/grub2/keyb_de.gkb
generate the keymap: grub2-kbdcomp -o /boot/grub2/keyb_de.gkb de
then run update-bootloader reboot
but the keyboard layout for the passphrase is still US.
Yes, modules can be preloaded but layout file is still missing (and adding it to grub.cfg is anyway too late). This can be worked around by using grub2-mkstandalone to add internal memory disk with layout file and modifying embedded config to explicitly point to memdisk location to load layout file. But that of course cannot be integrated into update-bootloader currently. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
19.05.2018 00:00, Frank Kunz пишет:
[2] https://superuser.com/questions/974833/change-the-keyboard-layout-of-grub-in...
at_keyboard was really intended for bare-metal systems where grub itself was primary payload of coreboot or similar. On PC BIOS or EFI it will compete with firmware for keyboard handling. I successfully hung system with it :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On May 18 23:00 Frank Kunz wrote (excerpt):
... I use special characters for my passphrase, which should be a good idea for a passphrase, and grub2 uses a different keyboard layout than the Linux installation. By that I need to type two different passphrases.
see "Some side notes for the fun of weirdness" and therein in particular "Use non-ASCII characters in usernames and passwords to lock yourself out" in https://en.opensuse.org/SDB:Plain_Text_versus_Locale What makes a passphrase good is first and foremost length. Length is more important than the size of the character set because the formula is number_of_words = size_of_character_set ^ word_length e.g. with only 36 ASCII lowercase alnums (i.e. 0-9 and a-z) versus all 95 printable ASCII characters it is e.g. 36 ^ 13 > 95 ^ 10 so that a passphrase with 13 ASCII lowercase alnums is better than a passphrase with 10 printable ASCII characters and in the same way is e.g. 36 ^ 17 > 95 ^ 13 so that a passphrase with 17 ASCII lowercase alnums is better than a passphrase with 13 printable ASCII characters and so on... Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.05.2018 um 09:56 schrieb Johannes Meixner:
Hello,
On May 18 23:00 Frank Kunz wrote (excerpt):
... I use special characters for my passphrase, which should be a good idea for a passphrase, and grub2 uses a different keyboard layout than the Linux installation. By that I need to type two different passphrases.
see "Some side notes for the fun of weirdness" and therein in particular "Use non-ASCII characters in usernames and passwords to lock yourself out" in https://en.opensuse.org/SDB:Plain_Text_versus_Locale
What makes a passphrase good is first and foremost length.
Length is more important than the size of the character set because the formula is
number_of_words = size_of_character_set ^ word_length
e.g. with only 36 ASCII lowercase alnums (i.e. 0-9 and a-z) versus all 95 printable ASCII characters it is e.g.
36 ^ 13 > 95 ^ 10
so that a passphrase with 13 ASCII lowercase alnums is better than a passphrase with 10 printable ASCII characters and in the same way is e.g. 36 ^ 17 > 95 ^ 13 so that a passphrase with 17 ASCII lowercase alnums is better than a passphrase with 13 printable ASCII characters and so on...
Kind Regards Johannes Meixner
This is a good hint, but if I want to keep my password and passphrase in sync I need to follow the company (where I work) password guideline. And this requires special chars :-/ Br, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On May 23 20:13 Frank Kunz wrote (excerpt):
... I need to follow the company (where I work) password guideline. And this requires special chars :-/
Sigh! I know, I know, I also suffer from that annoyance at various places where I need a password. It seems there is a general "company/organization disease" that had currently infected many companies/organizations which makes them require various special rules for the characters in their passwords - the more the better! Obviously each password requirement shrinks the search space so that the more requirements there are the easier it gets to guess a password by computers while at the same time the more requirements there are the more difficult it gets to remember such artificial passwords by humans (e.g. WTF were the upper case characters in my password?) which leads to various kind of "notes" where humans try to somehow keep those "inhuman" passwords, cf. https://xkcd.com/936/ "Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess." I think for companies/organizations it seems not to matter to make things actually more secure. It seems what matters more is that companies/organizations can feel safe because they had enforced the right (well known/old) rules and then when things go wrong they can claim it is not their fault. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/05/18 05:09 AM, Johannes Meixner wrote:
I think for companies/organizations it seems not to matter to make things actually more secure. It seems what matters more is that companies/organizations can feel safe because they had enforced the right (well known/old) rules and then when things go wrong they can claim it is not their fault.
See also: https://arstechnica.com/information-technology/2013/06/password-complexity-r... <quote> A pair of studies done in 2011 and 2012 on password length and construction showed two things: first, customer frustration increases significantly with complexity, but less so with length. Second, a number of password cracking algorithms can be more easily thwarted by a long password that is created without number, symbol, or case requirements than are shorter passwords that are required to be complex, particularly for a large number of guesses. That is, shorter, more complex password restrictions beget passwords that can be more frustrating to everyone except the only entity who shouldn’t have it: the password cracker. </quote> In practical terms, because of the buffer sizes and hashes, a length limit of 512 characters should be considered adequate for most purposes. I would, however, point out that Leo Marks mentions in his book "between Silk and Cyanide" that picking a phrase from a poem or nursery rhyme (or movie or novel) may defeat traditional computational and combinatorial methods, it won't defeat a human versed in your culture. In modern terms that means a high speed AI with access to the Net, YouTube, Guttenberg and more can draw on sources and resources. Eventually there will be AIs that run an emulation of you.... But for now, length beats complexity. The real pisassnts are the 4 digit PIN codes ... -- Quality is free, but only for those who are willing to pay heavily for it. -- Tom Demarco, "Peopleware" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-05-24 14:25, Anton Aylward wrote:
On 24/05/18 05:09 AM, Johannes Meixner wrote:
I think for companies/organizations it seems not to matter to make things actually more secure. It seems what matters more is that companies/organizations can feel safe because they had enforced the right (well known/old) rules and then when things go wrong they can claim it is not their fault.
See also: https://arstechnica.com/information-technology/2013/06/password-complexity-r... <quote> A pair of studies done in 2011 and 2012 on password length and construction showed two things: first, customer frustration increases significantly with complexity, but less so with length. Second, a number of password cracking algorithms can be more easily thwarted by a long password that is created without number, symbol, or case requirements than are shorter passwords that are required to be complex, particularly for a large number of guesses. That is, shorter, more complex password restrictions beget passwords that can be more frustrating to everyone except the only entity who shouldn’t have it: the password cracker. </quote>
In practical terms, because of the buffer sizes and hashes, a length limit of 512 characters should be considered adequate for most purposes.
I would, however, point out that Leo Marks mentions in his book "between Silk and Cyanide" that picking a phrase from a poem or nursery rhyme (or movie or novel) may defeat traditional computational and combinatorial methods, it won't defeat a human versed in your culture. In modern terms that means a high speed AI with access to the Net, YouTube, Guttenberg and more can draw on sources and resources. Eventually there will be AIs that run an emulation of you.... But for now, length beats complexity.
Like scanning facebook and others :-p
The real pisassnts are the 4 digit PIN codes ...
I know banks that use that. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hello, On May 24 11:09 Johannes Meixner wrote (excerpt):
On May 23 20:13 Frank Kunz wrote (excerpt):
... I need to follow the company (where I work) password guideline. And this requires special chars :-/
Sigh! I know, I know, I also suffer from that annoyance at various places where I need a password.
right now it happened that I got a nice example of elaborated password requirements. It shows this text: ------------------------------------------------------------------- Please enter your new password. The setting of the password is allowed only once a day. The password must not contain your given name, surname and userid. The password must not contain more than three identical characters. It must consist of 8-12 characters, at least one uppercase letter, at least one lower case letter, at least one number and at least one special character. Permitted special characters: ! $ % & ( ) = ? * + # - _ . : ------------------------------------------------------------------- Additionally that site requires me to replace my password relatively often (every few month) and of course it remembers my old passwords (hopefully a hash but I won't trust them so far) because another requirement is that a new password must not have been used before. Readers skilled in combinatorical analysis may calculate how much those requirements shrink the search space and how much easier all those requirements make it for computers to guess such passwords. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On jeudi, 24 mai 2018 17.07:38 h CEST Johannes Meixner wrote:
Hello,
On May 24 11:09 Johannes Meixner wrote (excerpt):
On May 23 20:13 Frank Kunz wrote (excerpt):
... I need to follow the company (where I work) password guideline. And this requires special chars :-/
Sigh! I know, I know, I also suffer from that annoyance at various places where I need a password.
right now it happened that I got a nice example of elaborated password requirements.
It shows this text: ------------------------------------------------------------------- Please enter your new password. The setting of the password is allowed only once a day. The password must not contain your given name, surname and userid. The password must not contain more than three identical characters. It must consist of 8-12 characters, at least one uppercase letter, at least one lower case letter, at least one number and at least one special character. Permitted special characters: ! $ % & ( ) = ? * + # - _ . : -------------------------------------------------------------------
Additionally that site requires me to replace my password relatively often (every few month) and of course it remembers my old passwords (hopefully a hash but I won't trust them so far) because another requirement is that a new password must not have been used before.
Readers skilled in combinatorical analysis may calculate how much those requirements shrink the search space and how much easier all those requirements make it for computers to guess such passwords.
Kind Regards Johannes Meixner
I share the same pain in some places where I work :-) and when the said 3 identical characters it can means type of characters so not allowed abc you have to use ab2 :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[...] I need to follow the company (where I work) password guideline. And this requires special chars :-/
A wordaround is to find out once which special characters are the same on your keyboard and a US keyboard and then only pick from this set when creating new passwords. For example, for a German keyboard you could use ,.!$%. (In this case, you also must avoid z and y as they are swapped on a German keyboard.) You can find the US layout by searching for it with your favourite search engine. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Adam Mizerski -
Ancor Gonzalez Sosa -
Andrei Borzenkov -
Anton Aylward -
Bruno Friedmann -
Carlos E. R. -
francesco.vo＠tutamail.com -
Frank Kunz -
Joachim Wagner -
Johannes Meixner -
Oliver Kurz -
Werner LEMBERG