Security first. A little game theory.

See how different attacks are mitigated

Theoretical attack scenarios to drain a connected wallet balance:

1…Compromised login credentials, Phishing checkout page, credentials stuffing attacks.

Problem:

• An attacker might be able to log in to the user’s account.

Mitigation:

• On the Checkout page Passkey authentication lets the user connect a secure device, Android, Iphone, Yubi Key to mitigate these problems.

• On the dashboard, the attacker needs to compromise the crypto wallet of the customer to withdraw deposited balance from virtual accounts.

2…Compromised login and authenticator

Problem:

• An attacker physically compromised the device used for logging the customer in.

Mitigation:

• The smart contract account passwords are checked with zxcvbn, which is a password strength estimator inspired by password crackers. The users can only enter strong passwords for the AES encryption that are hard to brute force.

• The smart contract accounts can be closed by the EOA that created them any time. The EOA can be kept in cold storage somewhere else while making payments from it.

3… Compromised DebitLlama servers:

Problem:

• An attacker infiltrated the backend and aquired the decryption keys

Mitigation:

• The AES encryption enforces strong passwords that are hard to crack.

• Smart Contracts are pausable and all direct debit can be halted by the owner, which is a private key stored securely off-chain!

• While the direct debit is halted, the accounts can be disconnected and balances can be withdrawn with the connected EOA. Funds are never locked!

4… Compromised Relayers:

Problem:

• The Attacker infiltrated the relayers, aquired zero-knowledge proofs.

Mitigation:

• The ZKP circuit does not allow modification of the ZKP parameters, the attacker will be unable to withdraw any balances to his address. He can only relay transactions. The relayers could be actually anyone and I’m considering allowing external users to run one.

5… Accidental subscriptions created:

Problem:

• The user created subscriptions that he don’t want to pay for.

Mitigation:

• Subscriptions can be cancelled any time using the EOA of the account.

• After creating a subscription, there is a 30 minute window to cancel them and an Email notification is sent. If an somebody’s account is fully compromised, then the EOA is used to close it.

• Virtual accounts and connected wallets also have spend limit! If an approved allowance or deposited amout is exceeded, the payments halt. Don’t approve more than you can spend.

6… Compromised smart contract owner:

Problem

The smart contract owner (me) is physically compromised. The private key controlling the smart contract was stolen.

Mitigation

• The smart contract owner has no access to the balances of the accounts.

• He receives fees from transactions and can halt the direct debit. That’s all. A compromised owner would be catastrophic, (means somebody put a gun to my head) but would not result in any loss for the users.

I welcome any more theoretical attack scenarios .