This project has moved and is read-only. For the latest updates, please go here.

Restrict number of password attempts

Topics: Feature Requests
Jul 28, 2015 at 3:15 AM
I placed this comment under the issues tab but I am not sure if it was the correct place. Please let me know if this feature has been previously mentioned.

I have Full Disk Encryption running now but what I would like to see is if I enter the incorrect password "x" number of times and wipe the hard drive.

If possible the owner could disable any warnings so someone that steals the laptop won't know they have "x" attempts.

I mentioned earlier that I guess it will not stop people from cloning and then retrying more passwords but my main concern is more random theft and a few password attempts rather than anything too sophisticated.

Is this feature something that maybe able to be implemented or is it in the development queue?
Jul 28, 2015 at 5:30 AM
Edited Jul 28, 2015 at 6:19 AM
From a technical prospective, I do not see this being feasible between reboots of the PC because you would need to store the number of password attempts in the header key which is not possible without the correct password, keyfiles and/or PIM.

However during a given session, the program does keep password attempts for non-system encryption. After two failed attempts, the program automatically uses the backup embedded header key.

I believe it would be possible to have user configurable number of failed mount attempts for a single session and allow user configurable display or not display warning messages so a thief does not know they have limited password attempts. The default would be unlimited password attempts and this would provide backward compatibility.

I think the user screen for setting the number of password attempts should provide warnings about cloning and that the counter is only for a single session and will start its counter back to 1 if the PC is rebooted.

Wiping the hard drive will take a long time. I am not opposed to the idea. However I would suggest first wiping all the header keys and where applicable the embedded backup header key before starting to wipe the volume(s).

Now to play devils advocate. Once the word get out on the street that any computer encrypted with VeraCrypt needs to be rebooted between password attempts to avoid the "wipe" feature, is this request still a viable feature?

BEGIN EDIT:

In order to store the user configurable value of number of failed mount attempts, you would need to store the value in the clear (unencrypted) since the header key can only be decrypted with the correct password, keyfiles and/or PIM.

Storing values unencrypted removes plausible deniability for volumes.

I do not believe it will be acceptable to have this feature request implemented since it would introduce storing values unencrypted and removes volume plausible deniability.

END EDIT.

From the manual:
Note: If the user fails to supply the correct password (and/or keyfiles) twice in a row when trying to mount a volume, VeraCrypt will automatically try to mount the volume using the embedded backup header (in addition to trying to mount it using the primary header) each subsequent time that the user attempts to mount the volume (until he or she clicks Cancel).
.
@Mounir,

FYI: Include the PIM in the Tools -> Restore Volume Header section of the manual.
Note: If the user fails to supply the correct password, keyfiles and/or PIM value ....
Aug 3, 2015 at 1:14 AM
I just wanted to say thank you for a detailed reply. I am completely new to these ideas and I really appreciate the information.

I understand that we can't store a counter between sessions and every reboot would reset the counter back to 0. For my situation that would be good enough. It would put my mind at ease if there was some random theft. The most probable situation is they have a couple of password attempts, have no success and they throw out the hard drive as the header keys (and maybe the drive itself) have been wiped.

I also understand the problem you mentioned about plausible deniability. This is not an issue I would face and I would have no idea how to overcome that issue which makes it hard if compromises a feature people use.

I don't know if maybe the password counter feature could only be enabled if the user selects it when creating a system disk or container. That way people like me have the option to activate the feature and people who want plausible deniability could not activate the feature. Just an idea but not sure if something like that could be possible.