Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added address Verification #1

Open
wants to merge 24 commits into
base: main
Choose a base branch
from

Conversation

gavinharris-dev
Copy link

Added the method verifyAddress; this method takes the provided Public Key and Address (supplied by the signing process signData) and we attempt to recreate the address.

To recreate the address we get the stakeKeyHash and combine it with the publicKeyHash to create a 'reconstructed' address. We then verify that both the 'reconstructed' address matches the address provided when signing the data (token).

This change is to try and prevent actors spoofing a token. Prior to this change, in theory (in my head so it may not be correct) a user could create a signed token with any address as there was no verification that the Public Key (used to verify that the token has not been tampered with) belongs to the address that this token is making claim to.

@gavinharris-dev
Copy link
Author

src/lib/verify.js Outdated Show resolved Hide resolved
src/lib/verify.js Outdated Show resolved Hide resolved
src/lib/verify.js Outdated Show resolved Hide resolved
src/lib/verify.js Show resolved Hide resolved
@pyropy
Copy link
Owner

pyropy commented Dec 1, 2021

Linking PR with the Issue ticket #2

@pyropy
Copy link
Owner

pyropy commented Jan 21, 2022

Hey buddy, do you need some help with this? Give me a shout if I can help somehow :D

@gavinharris-dev
Copy link
Author

Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.

@pyropy
Copy link
Owner

pyropy commented Jan 24, 2022

Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.

No problems, I completely understand. Take your time and let me know if you need anything 😄

@gavinharris-dev
Copy link
Author

Do we want to look at getting this Merged? If you have time to do a further review?

@pyropy
Copy link
Owner

pyropy commented Feb 9, 2022

Do we want to look at getting this Merged? If you have time to do a further review?

Hi there, I'll take a look at it later today ⏰

@pyropy
Copy link
Owner

pyropy commented Mar 16, 2022

@gavinharris-dev Hi, I see that you're making quite a lot of progress. Request review when you are ready.

Also, if you could remove the commited dist directory it would be awesome 🙌🏻

@chrizcros
Copy link

Hey @gavinharris-dev @pyropy wanted to check if there is any progress on this pull request?
When I test out the PR I got the error:

Error: "signature" argument should be a function that returns a signature string (Promise<string>) at _callee$ (sign.ts?b2ef:9:1) at tryCatch (runtime.js?96cf:63:1) at Generator.invoke [as _invoke] (runtime.js?96cf:294:1) at Generator.eval [as next] (runtime.js?96cf:119:1) at asyncGeneratorStep (asyncToGenerator.js?1da1:3:1) at _next (asyncToGenerator.js?1da1:25:1)

The reason is that api.signData is a string and not an object:
image

await Web3Token.sign((msg: string) => api.signData(address, toHex(msg)), '1d')

Do you have an idea how to handle that?

@gavinharris-dev
Copy link
Author

Hi @bieric,

Here is an example that I am currently using in our Application. This is using my main branch i.e.,

"dependencies": { 
...
"web3-cardano-token": "gavinharris-dev/web3-cardano-token",
...
}
const getLoginToken = async (wallet) => {
  const address = await wallet.getUsedAddresses();

  if (!address || address.length === 0) {
    throw new Error('No wallet address');
  }

  return await Web3Token.sign(async (msg) => {
    return await wallet.signData(address[0], Buffer.from(msg).toString('hex'));
  });
};

Wallet.signData (according to CIP30 and implemented on Nami Wallet) will return the type DataSignature which is structured as such:

type DataSignature = {|
  signature:cbor\<COSE_Sign1>,
  key: cbor\<COSE_Key>,
|};

The DataSignature type is the expected return type for the Callback method provided into Web3Token.sign.

Note: Older versions of Nami Wallet (and perhaps other Wallets) returned a CBOR String as a result of the signData method, I should probably (when allowing users to link a wallet) check that not only is the Wallet supported, but also the Version provided is supported.

In terms of getting this PR merged in, I think (with the extend of the code changes) it would be highly useful to get the code reviewed again. Also really need to work out how to write some Unit Tests for these changes! I need to verify several things now:

  • Provided Token is Signed correctly; i.e., with the Private Key of the supplied Address,
  • Provided Token has not been tampered with, i.e., the Signature matches a 'recalculated' signature,
  • Provided Token is still 'in date'; I.E., has not expired,

I also think that there is a discussion around packaging; I have on my branch the Dist folder where I have the build artifacts available. This is probably undesirable but I'm too new to developing JS modules to know what the process should be; so any tips would be appreciated!

Ref:
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apisigndataaddr-address-payload-bytes-promisedatasignature

@bitlands
Copy link

@gavinharris-dev Thank you a lot for your detailed description!

Unfortunately, I have still some problems.
I'm trying it with Nami and Eternl wallet.

I guess eternl is still returning the CBOR string.
image

Nami has other problems (v3.2.1):
image

My questions:

  1. What wallet/version do you use?
  2. When a wallet returns a CBOR string do you have an example of how to handle it?

I also want to help maintain this repository since it could be a huge deal for the Cardano community but first I would like to have a working example to better understand it.
Thank you in advance!

@gavinharris-dev
Copy link
Author

gavinharris-dev commented Apr 18, 2022

What wallet/version do you use?

We use Nami 3.2.1 and get good results. The error you are getting with Nami appears to be thrown in 3 places (in the Nami code):

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L694

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L721

Without seeing how you are using the library I'm not really able to help much here. Perhaps print out the inputs that you are sending to signData so that you can verify that they are valid HEX encoded values (you need to verify that the address input is in-fact an address and that the 'data' can be decoded back to plain text).

Perhaps if you can post a small example that we can work through it?

When a wallet returns a CBOR string do you have an example of how to handle it?

This is a great question; @pyropy should we be looking to support the 'old' sign data structure? It looks like the community has settled towards the CIP30 version of signData and so my opinion would be that we would not support the return of CBOR string.

@pyropy Do these discussions need to move into an Issue / Discussion rather that a Pull Request?

@bitlands
Copy link

@gavinharris-dev Thank you a lot I've found the issue. I've decoded the address to the readable string and not let it in the hex format. That's why the signer fails.

Thank you again!

@pyropy
Copy link
Owner

pyropy commented May 4, 2022

Hey folks, sorry for being absent lately -- I've focused mostly on my day job.

@gavinharris-dev When wallet returns CBOR I guess simplest way is for user to simply handle the decoding process -- we should always stick with the CIP implementation.

Is the PR ready to be reviewed?

@chrizcros
Copy link

@pyropy I agree. Yes I think so. I've tested it with Nami and it works good.

Copy link
Owner

@pyropy pyropy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks awesome! Thank you so much for your contributions so far 🎉

I'll test it and once we're sure that it's working properly I'm going to merge it finally 😮‍💨

package.json Outdated
@@ -1,12 +1,13 @@
{
"name": "web3-cardano-token",
"version": "0.0.12",
"version": "0.1.17",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would stick with version 0.1.0 here perhaps. If the API has no breaking changes then I would just increase it to 0.0.13.

};

export default Web3Token;

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Types ❤️


type Signer = (msg: string) => PromiseLike<COSESign1>;

export function sign(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we stick with arrow function types? Also we should make first letter of the function uppercase ⏫

@@ -1,8 +1,15 @@
import Base64 from "base-64";
import parseAsHeaders from "parse-headers";
import { Buffer } from "buffer";
import Loader from "./loader";
import Loader from "./loader.js";
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is .js needed for import?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No its not needed

@chrizcros
Copy link

@pyropy Do you have an example how to decode the cbor string to make other wallets compatible?

@pyropy
Copy link
Owner

pyropy commented May 4, 2022

@bieric You should be able to decode CBOR using some libraries -- for example here's an JS library for encoding/decoding CBOR

https://github.com/paroga/cbor-js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants