The PasswordStore contract declare the s_password as private to store the password.
The aims of this password is that it should be only get and set by the owner contract.
However, from this current logic, users which are not the owner can get the s_password by using the eth_getStorageAt RPC Method to access storage the PasswordStore contract at the slot#1.
Users which are not the owner can get the s_password by using the eth_getStorageAt RPC Method to access storage the PasswordStore contract at the slot#1.
Since the private variables declared on chain is not actually private, the users can get both owner address (s_owner L13, slot#0) and the password (s_password L14, slot#0)
Since the private variables declared on chain is not actually private, the users can get both owner address (s_owner L13, slot#0) and the password (s_password L14, slot#0)
Consequently, If this password stroed in this contract is used for log-in to any other platfrom such as Gmail, facebook, twitter, the malicious user can get that password and log-in to that victim account.
Do not store the sensitive data on-chain.
(if want to store)It might be better if you storing on off-chain with the secure process and use just the ref to that password (ie. indexed on DB)
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.