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

[Suggestion] Hey everyone, this is as secure as you want it to be #92

Open
mattaereal opened this issue Mar 21, 2024 · 6 comments
Open

Comments

@mattaereal
Copy link

mattaereal commented Mar 21, 2024

Hi! I'm not related to this project at all, a friend sent me this and I thought I could help at least a little.

First of all, you're all right in being kinda paranoid, since you can get an information leak or even totally pwned by messing with containers if you don't know what you are doing. I don't know about the other methods, but this is what I did for him, though I do not make myself responsible for anyone doing silly things or not checking twice.

I suggested following these steps to my friend -> manual instructions, which are way more visually probable secure.

Through these steps

  1. You're not running anything custom this way, only curl, age, cargo, and xxd, and everything inside a container.
  2. You're not sending any private key anywhere.

The short explanation for these steps is that inside the metadata.bin, you have this sort of "challenge", associated with every eligible GitHub account. It is being done via those accounts' public keys since it is public information. For example, mine are github.com/mattaereal.keys.

This type of thing is a security measure to prevent people from getting usernames squatted, among other things.

Only the right holders of the ssh private key to that public ssh key are the ones that will be able to decrypt this kind of "challenge". And this is the only way or situation where you're going to use your private key, to use the command line age to decrypt that kind of information.

Then, if I'm not mistaken, since it's reusing Merkle proofs to validate this "challenge" has been solved, it created a temporary address with its respective private key, which is embedded inside the decrypted "challenge" and used to generate this proof. In the last commands, the second time you must provide information of your own is when you are asked to select your Ethereum address which is where you will receive the tokens.

And that would be it.

In the case of my friend, I did everything as the instructions suggested except I never introduced my ssh key in the container, and I just ran the command age on my host because I had it already installed. Pasted the decrypted data again into the container, and continued until I finished.

Again, I did this a few minutes ago and really really fast because I was leaving work, but I hope this clarifies a little. Am I only describing this situation because I saw many people from Latam trying to claim and right now that amount (if they were not to hold it) is a lot for underdeveloped countries. So I hope everyone who needs this may find a way to claim it.

Cheers.

@LeslieOA
Copy link

LeslieOA commented Mar 22, 2024

I did it this way:

  1. Clone repo to a VM
  2. Look at the available methods and say "hell nawww, this looks sketchy"
  3. wget the metadata.json file
  4. Disconnect VM from network
  5. Copy over web folder
  6. Run a simple HTTP server from the above folder e.g. python -m http.server
  7. Start process (as I already have age installed locally)

The least fear inducing way to generate proofs does feel like the above (although, it's needlessly paranoiad).

Would be an idea to host the web based tool on GitHub Pages, but maybe the "barrier to entry" is intentional. 🤷🏾‍♂️

@BillZong
Copy link

BillZong commented Apr 2, 2024

Well, It's safe so far using bash scripts.
I've checked the scripts carefully, and find out it is safe to use.
Can't guarantee 100% due to upstream age binary downloading, so make sure to re-check binary checksum if you can't be sure.

@habaneraa
Copy link

I am wondering whether I can first delete the public key (in GitHub Settings) and then utilize the corresponding private key to generate proof. If this is permissible, the process would be entirely secure. Even if a hacker manages to acquire my private key for proof, it would be futile since the corresponding public key for SSH authentication is no longer viable.

@mattaereal
Copy link
Author

The blob is a snapshot, so no matter what you do with your pub key on your github account, it won't change anything.

@matinzd
Copy link

matinzd commented Apr 10, 2024

@habaneraa If you want to make it as secure as possible, try to rotate all of your keys and remove the old public key from your Github account.
Removing the old one and putting it back when it's done it's not gonna help.

@Misaka-0x447f
Copy link

Yes just rotate keys once complete. ...And maybe, optionally, backup your old one.

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

No branches or pull requests

6 participants