Is there currently or planned to be a lockout mechanism?

[tcullum-rh]

I notice that if I enter an incorrect master password to the vault at load-up, there is an icon that appears at the bottom right in red with a loading bar. Presumably, this icon represents some type of rate-limiting or lockout mechanism. In fact, if I enter 10 incorrect passwords, 10 icons appears in serial, however, if I enter the correct password while these loading bars are still "in progress", I am able to login immediately.

[dominikwilkowski]

Hey @tcullum-rh
The icon as you call it is commonly referred to as a toast. (I found this while googling it for more infos: https://www.uiguideline.com/components/toast)
The bar that decreases just shows you for how long the toast is visible before it gets dismissed.

So to your question: we do not have a max password enter mechanism that will lock you out for a while before you can try again. It might be a good idea to implement this? It's not super effective though as someone who would like to crack the database would just take the vault_db.toml file and try to decode it as often as they want to since we don't have control over what they do or don't do at this point. The password enter mechanisms like you're talking about make the most sense for web interfaces where the password field or the request is the only way to access the database.

Having said all that I'm not against looking into building such a feature...

[tcullum-rh]

@dominikwilkowski I see, so it seems that this is just a toast to notify the user, but the toast itself has a progress bar on it, and I misinterpreted that progress bar to be some sort of time I needed to wait in order to be able to retry a login into vault.

Aside from that, regarding the feature itself, I agree. Not super effective if someone has access to the file but could be effective in these situations:

1. Casual, non-technical attempts (e.g. Jimmy steps out of his bedroom for 5 minutes, and his roommate runs in and tries to guess the password, which he may already know part of because it's partially Jimmy's birth year)
2. Situations where the system is setup in a way where the user's account itself actually cannot directly access the vault_db.toml file, but vault can. Configuring SELinux/ACLs/etc this way may actually be a decent hardening mechanism in certain circumstances. If vault is the only application that can touch the file, then I think something like this protection would matter more.

And this also begs the questions - who is the target audience for vault? Is it Jimmy? Is it purely sysadmins and technical users? I think that could shape the road map going forward as well.

Also, provided I have time to get my feet wet with Rust again (its been a while), and floem, I may submit some PRs in future as well.