Debian, encrypted boot, how to increase password attempts?
from boredsquirrel@slrpnk.net to linux@lemmy.ml on 26 Aug 08:48
https://slrpnk.net/post/26608840

Since Debian 13 (Trixie), when using the default FDE which uses grub to decrypt the luks partition, I have a single attempt

When the password is mistyped there is a long pause (over 10 seconds) and then the error appears.

I already tried increasing the max tries, which seems to be set to 1 when a keyfile is used.

The config/script seems to be in /usr/share/initramfs-tools/scripts/local-top/cryptroot.

I copied that to /etc/initramfs-tools/scripts/local-top/cryptroot and replaced the value CRYPTTAB_OPTION_tries=1 with 10 using find/replace (ansible stuff).

I think this has no effect though and doing so (might be a different issue) breaks boot entirely đź’€

More info:

#linux

threaded - newest

bacon_pdp@lemmy.world on 26 Aug 10:01 next collapse

There is no attempt limit in grub by default, just use cryptomount (hd0,msdos1) and type in the password; repeat until you get it right

Blue_Morpho@lemmy.world on 26 Aug 13:49 collapse

I think he’s referring to the 10 second pause between attempts. It’s security theatre because you can replace the bootloader with one that doesn’t pause.

derpgon@programming.dev on 26 Aug 18:04 collapse

Is it? I always though the password is hashed via Bcrypt (or similar) with very high difficulty so it takes some time to check

Blue_Morpho@lemmy.world on 26 Aug 19:27 collapse

Disk encryption is Luks not bcrypt and Luks timeouts are configurable.

derpgon@programming.dev on 27 Aug 21:21 collapse

So, it is purely a software timeout and not hardware due to key derivation algorithm? That’s partly understandable and partly a security hole if it can be disabled so easily.

communism@lemmy.ml on 26 Aug 10:39 next collapse

Newer versions of grub let you retry up to 3 times before going to grub rescue. Check if your grub is up to date, and if it is, wait for Debian to release the update to their repos I guess

ferric_carcinization@lemmy.ml on 26 Aug 11:15 next collapse

But bootloaders are distro/OS agnostic. Why wait for Debian, when you could, for example, boot an Arch live ISO to install a newer GRUB?

I don’t use GRUB, but have done the same thing with SystemD Boot before. As GRUB’s configuration system is a bit more complex, you might have to mount your main install to get the correct config file.

frongt@lemmy.zip on 26 Aug 12:08 collapse

If you’re going to do that, get the grub debs from Debian sid, not a whole different distro.

ferric_carcinization@lemmy.ml on 26 Aug 12:53 collapse

As it’s a bootloader, it should make almost no difference which distribution was used to install it. (I’m not sure if Debian patches their GRUB.) I just used Arch as an example, as it is famous for being up to date. And, no matter where it’s installed from, if you’ve made changes to GRUB’s configuration, you’ll have to copy it over to the live distribution to keep your changes.

Yes, Debian Sid might be more familiar for Debian users, but that’s it.

Edit: You said “get the grub debs from Debian sid”, but installing Sid packages on non-Sid systems isn’t something that you should do.

communism@lemmy.ml on 26 Aug 18:37 collapse

Why install it from a package manager at that point? It’s probably more of a pain to get an Arch package working on Debian than it is to just build GRUB from source and install it according to whatever instructions GRUB distributes

ferric_carcinization@lemmy.ml on 26 Aug 19:16 collapse

I meant the following:

  1. Find out the Debian package is too old
  2. Create Arch Live USB
  3. Boot Arch Live USB
  4. Copy GRUB config from the Debian install to the current Arch live system
  5. Install the up-to-date GRUB while in the Arch environment

The bootloader installer package is distro dependent, the bootloader the package installs isn’t. You can boot Debian no matter if the GRUB is installed from Debian stable, Debian Sid, Arch, Fedora or even FreeBSD. Otherwise, dual booting wouldn’t work.

Like I said, I’ve done that before, though with SystemD Boot instead of GRUB, which was a bit simpler due to how the bootloader is configured.

boredsquirrel@slrpnk.net on 26 Aug 17:52 collapse

Interesting that might be the case. The install was Deb12, updated to 13. Might not have updated the grub.

But this happened AFTER the 13 upgrade, not before. So rather a newer grub version.

MimicJar@lemmy.world on 26 Aug 19:22 collapse

After you updated the config did you update-initramfs or update-grub (I forget which flags might be needed off hand).

Since this is happening pre-boot it isn’t reading from /etc.

boredsquirrel@slrpnk.net on 26 Aug 21:41 collapse

Hm, I only ran update-grub

Ran update-initramfs from the chroot trying to repair it

Found that there is a cleaner way in /etc/default/grub with grub commandline arguments. But that wants a source= variable which is weird to me as that hardcodes a drive in there that wasnt there first?

Tbh I will try this on a secondary laptop now, I reinstalled that thing like 5 times now and am a bit traumatized XD

Luckily we have more than enough