First Flight #1: PasswordStore

Summary

Add a Timelock to Critical Parameter Change

Vulnerability Details

It is a good practice to give time for users to react and adjust to critical changes with a mandatory time window between them. The first step merely broadcasts to users that a particular change is coming, and the second step commits that change after a suitable waiting period. This allows users that do not accept the change to withdraw within the grace period. A timelock provides more guarantees and reduces the level of trust required, thus decreasing risk for users. It also indicates that the project is legitimate (less risk of a malicious Owner making any malicious or ulterior intention). Specifically, privileged roles could use front running to make malicious changes just ahead of incoming transactions, or purely accidental negative effects could occur due to the unfortunate timing of changes.
similar findings:
https://code4rena.com/reports/2022-01-sandclock#m-05-add-a-timelock-to-basestrategysetperffeepct

Impact

Consider extending the timelock feature beyond contract ownership management to business critical functions. Here are some of the instances entailed:
https://github.com/Cyfrin/2023-10-PasswordStore/blob/main/src/PasswordStore.sol#L26

Tools Used

Recommendations