First Flight #1: PasswordStore

Summary

There are no validations for empty strings or identical strings in the setPassword function.

Vulnerability Details

The setPassword function in the current contract design allows users to input any string as the password, including empty strings or a string identical to the currently set password. This lack of validation may have the following consequences:

1. Empty Strings: The ability to set an empty password compromises the intention behind having a password in the first place. Even though an empty password may not have immediate security implications (given the restricted access), it can still lead to unexpected behavior for any frontend or external systems interfacing with this contract expect if these expect the password to be non-empty.

2. Identical Strings: If users mistakenly or intentionally set the password to its current value, they will pay gas fees for an actions than brought no state change.

Impact

The impact is minimal for security purposes.

If the user submits an empty string as a new password, the contract will behave as expected, accepting the empty password. However, there is a potential mismatch if a frontend associated with this contract expects a non-empty string, potentially leading to unexpected behavior or bugs.

Similarly, if the user submits their current password as the new password, the contract behaves as intended, but users will expend gas fees without causing any state change in the contract.

Tools Used

Manual code review.

Recommendations

In the setPassword function, I recommend adding two validations:

1. Prevent the setting of a password that's an empty string.

2. Disallow the submission of an existing password as the new password.

Below is a proof-of-concept (P.O.C.) for how these validations can be implemented: