PasswordStore Audit Report
Version 1.0
Tri-A-Sec
October 24, 2023
First Flight Code Hawks Contest October 24, 2023
First Flight Code Hawks Contest
stackangel22
October 24, 2023
Prepared by: [tri-a-sec LTD] Lead Auditors: - stackangel
Table of Contents
• Table of Contents
• Protocol Summary
• Disclaimer
• Risk Classification
• Audit Details
– Scope
– Severity Criteria
– Summary of Findings
– Tools Used
• High
• Medium
• Low
• Informational
• Gas
Protocol Summary
First Flight is a weekly code hawk challenge for new web3 code auditors. The protocol audited is
described as a PasswordStore a simple solidity protocol meant to allow the owner to store and retrieve
their password securely.

First Flight Code Hawks Contest October 24, 2023
Disclaimer
The Tri-A-Sec team makes all effort to find as many vulnerabilities in the code in the given time period,
but holds no responsibilities for the findings provided in this document. A security audit by the team is
not an endorsement of the underlying business or product. The audit was time-boxed and the review
of the code was solely on the security aspects of the Solidity implementation of the contracts.
Risk Classification
Impact
High Medium Low
High H H/M M
Likelihood Medium H/M M M/L
Low M M/L L
We use the CodeHawks severity matrix to determine severity. See the documentation for more details.
Audit Details
This is a first of weekly code challenges organised as first flight from code hawks
Scope
The code base consist of a single solidity file PasswordStore.sol which is in scope.
Severity Criteria
To standardize the evaluation, i define the following terminology based on https://docs.codehawks.com/hawksauditors/how-to-evaluate-a-finding-severity Methodology [11]: • Likelihood represents how likely a
particular vulnerability is to be uncovered and exploited in the wild; • Impact measures the technical
loss and business damage of a successful attack; • Severity demonstrates the overall criticality of the
risk. Likelihood and impact are categorized into three ratings: H, M and L, i.e., high, medium and low
stackangel22 3
First Flight Code Hawks Contest October 24, 2023
respectively. Severity is determined by likelihood and impact and can be classified into four categories
accordingly, i.e., Critical, High, Medium, Low
Summary of Findings
Here are the summary of our findings after studying the smart contract source code. Manual analysis
was all that was carried out to check if is fit for the purpose for which it was built and scrutinize for
possible pitfalls or bugs.
Severity # of findings
High 2
Medium 0
Low 0
Informational 0
Tools Used
No static analysis tools used for this purpose. # High (1) The Blockchain cannot be Used To secret data
as it is accessible and available for all to see.
Description
The PasswordStore protocol intends to keep data on-chain which is not practicable as data can be read
from a contract’s storage slots. In this case assuming the string state variable is stored in slot 1.
Using web3.js the exact content can be retrieved with the following code (AS described in the ethernaut
openzeppelin hacks).
password = web3.eth.getStorageAt(passwordStore.address, 1);
Also using solidity a function such as below could be used in getting the content of such storage slot
// SPDX-License-Identifier: MIT pragma solidity ˆ0.8.18;
contract PasswordReader { function readData(address target, uint256 slot) external view returns
(bytes32) { bytes32 data; assembly { // Calculate the storage slot key based on the provided slot
bytes32 slotKey := keccak256(slot)
stackangel22 4
First Flight Code Hawks Contest October 24, 2023
1 // Call the target contract's storage at the specified slot
2 sstore(slotKey, sload(slotKey))
3 calldatacopy(0, 0, calldatasize())
4 bool success := staticcall(gas(), target, 0, calldatasize(), 0,
0)
5
6 // If the static call was successful, load the result from the
returned data
7 if success {
8 returndatacopy(0, 0, returndatasize())
9 data := mload(0)
10 }
11 }
12 return data;
13 }
}
Passing the address of the contract and the slot number can get the private state variables. Sensitive
Data must not be stored on-chain for any reason, this goes against the intended use of the protocol, as
it is the core of why the protocol was built.

(2) Lack of Access Control for the setPassword Function.
Description ————— The setPassword Function does not make use of any sort of access control
to ensure only the owner of the contract can infact access the functionality of the function, which
is to set the s_password state variable.
function setPassword(string memory newPassword) external { s_password = newPassword; emit
SetNetPassword(); }
A smart contract can be written to interact with the external function to set the password without being
the owner, this is against the stated plan of the protocol.
An example solidity code that could be used to set the password

// SPDX-License-Identifier: MIT pragma solidity 0.8.18;
import “./PasswordStore.sol”;

contract setPassword is PasswordStore {
address owner;
PasswordStore public pwd = new PasswordStore();
error notowner(address sender);
1 constructor(){
2 owner = msg.sender;
3
4 }
5
6 function changePassword(string memory newpass)public {
7 if(msg.sender != owner)
8 revert notowner(msg.sender);
9 pwd.setPassword(newpass);
10
11 }
}
Solution
The protocol has to make use of a form of access control mechanism, either a modifier that accepts
only owner
modifier onlyOwner() { require(msg.sender == s_owner, “not owner”); _; }
Or carry out the same check used in the getPassword() function;
function setPassword(string memory newPassword) external { if (msg.sender != s_owner) { revert
PasswordStore__NotOwner(); s_password = newPassword; emit SetNetPassword(); }

Recommendations

It is highly recommended to avoid the storing of private secretive data on-chain as it can be retrieved by anybody. Also the use of access control is very important to be able to secure the protocol as needed.