What exactly is dangerous about it?
LUKS supports up to eight passphrases, that exist side by side and either of them can decrypt the volume. One may want to use a passphrase as fallback.

If you do not want a fallback just do not add extra passphrases. But please do not complain if your hardware with keyfile breaks.

The most important: Always use strong passphrases.

"If you do not want a fallback just do not add extra passphrases"
If you have a full disk encryption, you are required to have at least one passphrase. You will be asked for it before grub loads.
In case you add a keyfile, you will be asked for it post grub, as an extra secutiry measurement.
It make no sense to ask two times for the password, THAT'S THE WHOLE POINT OF ADDING AN EXTRA SECUTIRY LAYER.


"But please do not complain if your hardware with keyfile breaks."
You can easily setup backup keys using udev rules.

And please do not suggest to avoid encrypting /boot, because that's even more dangerous. One could inject a trojan into a ramdisk and execute basically whatever they want.

You can have one passphrase for /boot, another passphrase and keyfile for /. IMHO the code is correct.
Once again... What exactly is dangerous about it?

Oh wait and it's even better: When you are asking for the fallback password, there's not even attempts limit or time delay. Crackers must love your "feature".

"Once again... What exactly is dangerous about it?"
Anyone can see you while while you type. Passwords are not reliable.

Retries is limited to the compiled in default for cryptsetup of three. Timeout delay is enforced by the iterations count of the key derivation function for the keyslot.

Three attempts? I have way more than three here:
https://i.imgur.com/0jQmQKX.jpg

Even so. There's no reason for a fallback method.

What's the point of adding a USB keyfile if I can skip it completely and use a password instead? Password that, again, cannot be deleted from luks if you have a full disk encryption, like the one Manjaro and many other distros offer out of the box.

I think it is the while loop [1] which appears to keep looping with a two second delay? Note the prompt change in your image after the third attempt.
What do you mean password can not be deleted from LUKS? Both LUKS1 and LUKS2 allow keyslot changing and removal.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/hooks-encrypt?h=packages/cryptsetup#n87

Because when you have a full disk encryption, there's a pre-grub screen asking you for your luks password.
If you try to delete that password from luks you will be propted to introduce a valid password, when you do, it will be rejected (since it's the last one). So you won't be allowed to delete it, even if you have a keyfile on a different slot.

But you have a point there, even if I have both luks password and keyfile, that doesn't add any extra security. Anyone with the password could easily use a live cd to mount the unit and have full access.

Therefore, indeed it might not be your responsability.

EDIT: Now that I think about it... If the only way to boot into the system with a keyfile is by not encrypting /boot, but if you don't encrypt /boot then you are vulnerable to injections of code in the ramdisk. Then indeed, the current system is the only one truly secure, as long as no one know your password.

Andrian, can you elaborate on your logic (taking into account rethinking in last comment)? In luks, as in plain dm-crypt mode a key and a passphase are two views of the same 'secret' material, so if key is unavailable (because uderlying device is not inserted), then passphrase can be entered.

'If the only way to boot into the system with a keyfile is by not encrypting /boot, ...' Why?

Adrian, honestly if you don't protect your grub, someone can install trojan to your bootloader, if you don't protect your firmware, someone can put trojan there, etc... Or you get coldbooted, or someone just hacks you intel ME, or ...

Keyfile is convenience feature mostly i think, especially because grub cannot use it. At least in full-disk (except grub) encryption scenario.

If you need to have computer unbootable without USB drive, then put keyfile in initramfs, which you put on LUKS encrypted stick along with kernel and grub and boot from it.
Other option is to have /boot on separate partition (passowrd protected so GRUB can open it) and then you can have your / keyfile-only protected.

If LUKS doesn't allow for deleteing password, put something long enough there and forget it.

For most people current solution is enough, as it provides fallback in case of keyfile loss and still protects your data well enough. Others can create solutions they need.

There's nothing dangerous about it. PEBCAK.

Furthermore: A keyfile is just a password stored in a file. It does not change the fact that you need to supply a valid password to unlock the container. Example: `dd if=/dev/zero of=test bs=4M count=500; echo -n 'test' > luks.key; cryptsetup -d luks.key luksFormat test; cryptsetup open test blahblah`, then enter 'test' when prompted for the password.

If a keyfile is supplied, it can be used in-place of a user-typed password, if it satisfies the key. If it's not, it'll prompt you for the unlock password.

The error is not ambiguous; it tells you exactly what goes wrong.