Scribd
Upload
25 views7 pages

2024 Passwordstore Audit

The PasswordStore Audit Report identifies two high-severity issues: on-chain passwords are visible to anyone, and the setPassword function lacks access controls, allowing anyone to change the password. The report recommends rethinking the contract's architecture and implementing encryption for passwords, as well as adding access control to the setPassword function. Overall, the audit highlights significant security vulnerabilities that need to be addressed to protect user data.

Uploaded by

bdinesh1126
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
25 views7 pages

2024 Passwordstore Audit

The PasswordStore Audit Report identifies two high-severity issues: on-chain passwords are visible to anyone, and the setPassword function lacks access controls, allowing anyone to change the password. The report recommends rethinking the contract's architecture and implementing encryption for passwords, as well as adding access control to the setPassword function. Overall, the audit highlights significant security vulnerabilities that need to be addressed to protect user data.

Uploaded by

bdinesh1126
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

PasswordStore Initial Audit Report

Version 0.1

Feb 20, 2024


PasswordStore Audit Report

ARAVIND

Feb 20, 2024


PasswordStore Audit Report Feb 20, 2024

PasswordStore Audit Report

Prepared by: ARAVIND Lead Auditors:

• ARAVIND

Assisting Auditors:

• None

Table of contents

See table

• PasswordStore Audit Report


• Table of contents
• Risk Classification
• Audit Details

– Scope

• Protocol Summary

– Roles

• Executive Summary
– Issues found

• Findings

– High
* [H-1] Passwords stored on-chain are visable to anyone, not matter solidity variable
visibility
* [H-2] PasswordStore::setPassword is callable by anyone

Risk Classification
Impact

High Medium Low

ARAVIND 2
PasswordStore Audit Report Feb 20, 2024

High H H/M M

Likelihood Medium H/M M M/L

Low M M/L L

Audit Details

The findings described in this document correspond the following commit hash:
1 2e8f81e263b3a9d18fab4fb5c46805ffc10a9990

ARAVIND 3
PasswordStore Audit Report Feb 20, 2024

Scope
1 src/
2 --- PasswordStore.sol
Protocol Summary

PasswordStore is a protocol dedicated to storage and retrieval of a user’s passwords. The protocol is
designed to be used by a single user, and is not designed to be used by multiple users. Only the owner
should be able to set and access this password.

Roles

• Owner: Is the only one who should be able to set and access the password.

For this contract, only the owner should be able to interact with the contract.

Executive Summary

Issues found
Severity Number of issues found

High 2

Medium 0

Low 0

Info 0

Gas Optimizations 0

Total 0

ARAVIND 4
PasswordStore Audit Report Feb 20, 2024

Findings

High

[H-1] Passwords stored on-chain are visable to anyone, not matter solidity variable visibility

Description: All data stored on-chain is visible to anyone, and can be read directly from the

blockchain.

ThePasswordStore::s_passwordvariableisintendedtobeaprivatevariable,andonlyaccessed through the


PasswordStore::getPassword function, which is intended to be only called by the owner of the
contract.
However, anyone can direclty read this using any number of off chain methodologies

Impact: The password is not private.

Proof of Concept: The below test case shows how anyone could read the password directly from the
blockchain. We use foundry’s cast tool to read directly from the storage of the contract, without being
the owner.

ARAVIND 5
PasswordStore Audit Report Feb 20, 2024

1. Create a locally running chain


1 make anvil
2. Deploy the contract to the chain
1 make deploy
3. Run the storage tool

We use 1 because that’s the storage slot of s_password in the contract.


1 cast storage <ADDRESS_HERE> 1 --rpc-url http://127.0.0.1:8545
You’ll get an output that looks like this:

0x6d7950617373776f726400000000000000000000000000000000000000000014 You can then


parse that hex to a string with:
1 cast parse-bytes32-string 0
x6d7950617373776f726400000000000000000000000000000000000000000014
And get an output of:
Recommended Mitigation: Due to this, the overall architecture of the contract should be rethought.
One could encrypt the password off-chain, and then store the encrypted password on-chain. This would
require the user to remember another password on-chain to decrypt the password. However, you’d
also likely want to remove the view function as you wouldn’t want the user to accidentally send a
transaction with the password that decrypts your password.

[H-2] PasswordStore::setPassword is callable by anyone

Description: The PasswordStore::setPassword function is set to be an external function,


howeverthenatspecofthefunctionandoverallpurposeofthesmartcontractisthatThis function
allows only the owner to set a new password.
1 function setPassword(string memory newPassword) external {

2 @> // @audit - There are no access controls here


3 s_password = newPassword;

4 emit SetNetPassword();

5 }

Impact: Anyone can set/change the password of the contract.

Proof of Concept:

Add the following to the PasswordStore.t.sol test suite.


1 myPassword

ARAVIND 6
PasswordStore Audit Report Feb 20, 2024

1 function test_anyone_can_set_password(address randomAddress) public {


2 vm.prank(randomAddress);
3 string memory expectedPassword = "myNewPassword";
4 passwordStore.setPassword(expectedPassword);
5 vm.prank(owner);
6 string memory actualPassword = passwordStore.getPassword();
7 assertEq(actualPassword, expectedPassword);
8 }
Recommended Mitigation: Add an access control modifier to the setPassword function.
1 if (msg.sender != s_owner) {
2 revert PasswordStore__NotOwner();
3 }

ARAVIND 7

You might also like