The PasswordStore
contract stores the user's password directly in the s_password
variable, creating a serious security vulnerability.
In the PasswordStore
contract, the user's password is stored directly in the s_password
variable. This creates a serious security vulnerability because the password becomes easily accessible to unauthorized parties. Typical contracts should use secure methods such as hashing the password before storing it to ensure user privacy and security.
This issue has a high impact on the security of the contract. Storing the password directly in the s_password
variable makes the password easily discoverable and potentially accessible by anyone with access to the contract.
Manual Review
To fix this issue, should change the way the password is stored. Instead of storing the password directly, use a password hashing function before storing it in the s_password
variable. Consider using a secure hashing library such as keccak256 to protect the user's password from unauthorized access. This will enhance security and protect user passwords from exposure within the contract.
Private functions and state variables are only visible for the contract they are defined in and not in derived contracts. In this case private doesn't mean secret/confidential
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.