• Web3 developer Brian Guan lost $40,000 after accidentally posting his wallet’s secret keys publicly on GitHub, with the funds being drained in just two minutes.
  • The crypto community’s reactions were mixed, with some offering support and others mocking Guan’s previous comments about developers using AI tools like ChatGPT for coding.
  • This incident highlights ongoing debates about security practices and the role of AI in software development within the crypto community.
  • darklamer@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    107
    ·
    4 months ago

    The developer said he forgot that his secret keys were in the repository.

    If you have your secret keys in your repository you’ve already fucked up, long before you accidentally make that repository public.

    • BrianTheeBiscuiteer@lemmy.world
      link
      fedilink
      English
      arrow-up
      27
      arrow-down
      1
      ·
      4 months ago

      One of the first things you should do in a repo is add a .gitignore file and make sure there are rules to ignore things like *secret* or *private* etc. Also, I pretty much never use git add . because I don’t like the laziness of it and EVERY TIME one of my coworkers checked in secrets they were using that command.

      • lurch (he/him)@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        5
        ·
        4 months ago

        Even though that’s a good extra precaution, per person config data, such as keys, should be stored outside of the repo, eg. in the parent directory or better in the users home dir. There is zero reason to have it in the repo. Even if you use a VM/containers, you can add the config in an extra mount/share.

        • barsquid@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          4 months ago

          What’s the general consensus on storing encrypted data in the repo with the keys outside? I see people recommend that but I’m too paranoid and my secrets are very small in size so it hasn’t been necessary.

          • lurch (he/him)@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            4 months ago

            the format of the encrypted file can give the attackers an advantage. if your code reads the decrypted file, the attacker can guess the first line is a comment or the name of a setting. a savvy person can combine that with the algorithm to perform a “known plaintext attack”, for example by generating a number of possible passwords that would lead to files starting like that.

            • barsquid@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              4 months ago

              That’s smart. Anyone trying that should definitely have a machine-generated strong password!

      • JimmyMcGill@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        I basically always do a git add -p

        Very useful command and it works with other git commands as well.

        Everytime a colleague asks me for help with git that’s the one rule I suggest them to use.

          • PumaStoleMyBluff@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            4 months ago

            Instead of just adding whole changed files, it starts an interactive mode where it shows every hunk of diffs one by one, and asks you to input yes or no for each change. Very helpful for doing your own mini code review or sanity check before you even commit.

            • iegod@lemm.ee
              link
              fedilink
              English
              arrow-up
              1
              ·
              4 months ago

              I use vscode with plugins and manually add my files now. The workflow is beautiful.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        git add -u is pretty nice, it only adds modified files.

        I usually do git add -p which is interactive (helps avoid committing debugging prints and whatnot), but the other is nice for bigger refactors.

    • NOT_RICK@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      4 months ago

      And that’s why you always leave a note recheck your .gitignore file before committing

  • dhork@lemmy.world
    link
    fedilink
    English
    arrow-up
    48
    arrow-down
    1
    ·
    4 months ago

    I have no sympathy for him, if he is a crypto developer he knows how important those private keys are. And he also knows people scrape public areas all the time looking for keys just like that. The whole point of crypto is to be immutable, so that money is simply lost to him now.

    He seems to know how much of a dumb mistake that was, although his description of himself was a bit more colorful.

    • CallMeButtLove@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      4 months ago

      You’re not wrong about how important those keys are and how he definitely should have known better. But I at least have a little sympathy for the guy. Everyone makes mistakes from time to time, even with important stuff. Hopefully they are lucky enough not to lose 40k on one but unfortunately he wasn’t. Whether he should have known better or not, that just plain sucks.

    • redcalcium@lemmy.institute
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months ago

      The whole point of crypto is to be immutable, so that money is simply lost to him now.

      IIRC there are several cases where some group of people lost big enough coins and force most of the miners to fork to get their money back. Not bitcoin though.

      • jol@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        4 months ago

        If that doesn’t make everyone lose 100% trust in coins that do that, I don’t know what will.

  • lowleveldata@programming.dev
    link
    fedilink
    English
    arrow-up
    35
    ·
    4 months ago

    It must be automated for it to happen in 2 minutes. Which implies these kind of things happen often enough for someone to write a script for it.

    • tiramichu@lemm.ee
      link
      fedilink
      English
      arrow-up
      38
      ·
      edit-2
      4 months ago

      Yes, it absolutely is automated.

      There are bots running constantly looking for things that match patterns for exploitable credentials in public commits.

      AWS credentials

      SSH keys

      Crypto wallets

      Bank card info

      If you push secrets to a public github repo, they will be exploited almost immediately.

      • daddy32@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        4 months ago

        The scanning part is definitely automated by many different actors (for the gains or the “lulz”), but being this fast, also automated key usage (account draining) must have been implemented which is a bit more impressive…

        • Voroxpete@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          4 months ago

          Not really. All of the underlying mechanics of crypto are so simple that they can be very easily interacted with by bots. Bots make up the vast majority of all crypto trades; mostly wash trading, but also front-running attacks, scams or outright thefts like this one. There are so many exploitable flaws in crypto that every bug is basically a self-executing bug bounty.

    • partial_accumen@lemmy.world
      link
      fedilink
      English
      arrow-up
      25
      ·
      edit-2
      4 months ago

      If it was a script I wrote, it would have successfully stolen the $40k, but also stolen my own money and deposit both sets of money into a second intended victims account because I forgot to clear a variable before the main loop runs again.

    • nucleative@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 months ago

      There must be bots trolling GitHub for API keys, crypto secret keys, and other such valuable data

  • Jo Miran@lemmy.ml
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    4 months ago

    I use a text file version of a novel to back up my keys, then I store the key map in multiple cloud drives. For example, if the word is “lighting” then my key map for that word would be 487,5 (line 487, word 5). Easy to crack, if you know what novel I am using.

      • ArcaneSlime@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        It’s also even older in use in communicating secretly, known as a Book Cipher. You and your recipient get the same copy of a book and agree to one of a few numbering schemes, the plaintext message becomes numbers that correspond with words in the book.

  • k_rol@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 months ago

    I’m sad I didn’t see any comments saying he shouldn’t be using a $40k wallet key to test his software in the first place. Anything could happen with simple code mistakes…just get an empty wallet or one with a few bucks in it.

  • Johanno@feddit.de
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 months ago

    They made 2 errors.

    1. Use crypto

    2. Storing the key anywhere close to the repo.

  • 👍Maximum Derek👍@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    4 months ago

    If there was any sort of password / highly entropic string detection in their build pipeline it would have caught a wallet’s keys. They aren’t an excuse for lack of diligence, but they should still be in every pipeline where passwords or keys might have to get used.

    I’m terrible about building pipelines for most of my personal projects though, so I’m throwing rocks from my glass house here.

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 months ago

      A CI pipeline wouldn’t fix this since the code would be committed before the pipelines run. This needs to be caught on the dev’s machine with a pre-commit or pre-push hook.

    • barsquid@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months ago

      I like your CI plan but maybe they just needed some sort of sane policy. Like never commit plaintext keys to any repo. Never work with a $40k key in a new project under development. Never convert a private repo to public.