Bug 2326489

Summary:	RFE: Handling of too many wrong LUKS password/passphrase attempts
Product:	[Fedora] Fedora	Reporter:	Mike B. <mike>
Component:	plymouth	Assignee:	Ray Strode [halfline] <rstrode>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	agurenko, gnome-sig, hdegoede, ivan.deschenaux, rstrode, summonholmes
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mike B. 2024-11-15 16:00:57 UTC

Description:
On a standard Fedora installation with LUKS disk encryption (e.g. / and /home subvolumes), the system only accepts two failed password/passphrase attempts. Upon third attempt with wrong passphrase, Plymouth splash screen stays on for what it seems a really log time (a couple of minutes), with no message indicating the issue. Afterwards the system enters emergency mode.

While this is the currently the expected behaviour of LUKS in Plymouth, an enhancement is most welcome.

Reasoning:
- Users not aware of this behavior have no feedback from the system letting them know that their last passphrase entered was still rejected, therefore they won't take action. They can only suspect something went wrong, since the boot process normally takes way less time before reaching the display manager.
- Users knowing this behavior might choose not to wait until access to shell is granted, and force reboot the system, in order to have faster access to a new login trial.
- Hitting `Esc` is of no use either, the user being presented with a long repetition of `dracut-initque` warning lines mentioning initiation of timeout scripts.

Possible enhancement:
User is granted a specified number of attempts, after which the system is brought to a halt, preferably with a prior error message.

It's being assumed that the system can't let the user enter wrong passphrase indefinitely for security reasons, hence the shutdown proposal.

It is also understandable that at this early stage of the boot process there is no information about the user's language preference, this being possibly one of the reasons why there currently isn't any message about wrong passphrase entered. However, given that the system language is English, a message before shutting down the system (according to this proposal) would still be better than no message at all, e.g.:

*Too many failed attempts. Powering off the system.*

Who would benefit from the enhancement:
Mainly desktop users (with emphasis on laptop users), this being the group with most users choosing disk encryption. It's the same group who would value good UX design.

Comment 1 Ivan Deschenaux 2025-06-17 09:13:01 UTC

I fully agree. Having recently moved to Fedora, I found the default behaviour quite surprising. A message to the user seems important, and there is at least some evidence that new users are confused by this, see https://discussion.fedoraproject.org/t/encrypted-boot-fails-sometimes-on-fedora-42/152696

I was previously using debian, where the default behaviour is to prompt the user for passwords indefinitely, until the partition containing /root can be decrypted and mounted. Perhaps this set my own expectations and explains why I was surprised by Fedora's handling of wrong password attempts, but nevertheless, the security benefits gained by failing to boot altogether seem low to me. The password prompt we are talking about happens during the boot process. I believe this means an attacker would have to gain physical access to the machine to attempt an attack, at which point they may as well remove the encrypted drive and attempt to decrypt it using a machine of their own. (In fairness, I suppose there may be some gains if we are talking about a laptop, in which case physically removing the drive may be impractical or impossible.)

As a quick note for anybody who wants to change this behaviour on their own machine, and who might find this bug report: this can be achieved by adding the option "tries=0" to the relevant line in /etc/crypttab and regenerating the initramfs with "dracut --force". "tries=0" will allow unlimited attempts, adjust as required.

Comment 2 summonholmes 2025-11-21 16:00:37 UTC

Agreed.  Still present in F43.  From a new user's perspective, I don't like this design choice.  The prompt looping indefinitely without any indication of what's wrong left me with a negative impression.  A new user may also not know what key(s) to press on the keyboard to indicate that something is wrong with the boot sequence.

There was also discussion here: https://discussion.fedoraproject.org/t/feedback-collection-of-test-week-for-the-anaconda-web-ui-installer-for-fedora-workstation/135846/24.

This RFE is over a year old and I don't want it to get buried in the weeds.  I know that Fedora isn't considered a distribution for beginners, but users new to Fedora shouldn't have to edit crypttab to get a user-friendly boot sequence.