Announcing ic-siwe v0.1.0 - Security fixes, making nonce required

Hi hackers! I’ve release a new version of the ic-siwe library.

Ic-siwe allows you to onboard Eth users onto ICP applications using the browser wallet plugin they love the most - Metamask!

This release introduces breaking changes with new call signatures for the prepare_login and login functions.

This PR focuses on improving the security and reliability of the SIWE (Sign-In with Ethereum) process by ensuring proper cleanup of SIWE messages, implementing nonce-based security measures, and validating signature expiration. These changes help prevent replay attacks and ensure that expired signatures are not accepted.

Key Changes

  • Ensure Expired SIWE Messages Removal: Added logic to remove SIWE messages on failed login attempts to prevent stale data retention.
  • Nonce Generation for SIWE Messages: Implemented nonce generation for SIWE messages to enhance security by preventing replay attacks.
  • Signature Expiry Validation: Added functionality to return an error if a signature has expired.
4 Likes

Is it possible to configure two domains or uris in the provider canister? I am thinking of the situation where you have a frontend hosted in a canister on a domain A=canister-id.icp0.io and have configured a custom domain B=example.com. Can I make it such that users can log in from both uris without getting a warning in Metamask?

1 Like

The provider canister can be configured not to include the website url in the hash that is used as seed for the generated identity. Which means you can switch the domain of your website without risking users loose access.

But no, currently you can’t configure multiple allowed domains. A SIWE message can only be tied to one domain name. Extending the provider canister to support multiple domains would be quite straight forward though. The provider canister would have to support adding “allowed domains”. When requesting a SIWE message, the caller would then need to specify for which allowed domain.

Can this problem be solved by the frontend code? Is there something the frontend code can do, dynamically from knowing if its origin is A or B, when calling the provider canister that would prevent the warning in both cases? I guess not, for otherwise it wouldn’t be safe I guess. Or?

Just double checking. Not including the website url is the default, right? Including the url in the derivation requires me to do something, to set the runtime option, correct?

Nope, need to be solved at the canister level. Allowing the frontend to change the domain would be insecure.

Yep, not including it is the default.