this post was submitted on 07 Jun 2024
529 points (98.2% liked)

Technology

60082 readers
4626 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 2 years ago
MODERATORS
 
  • 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.
top 50 comments
sorted by: hot top controversial new old
[–] darklamer@lemmy.dbzer0.com 372 points 6 months ago (4 children)

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 92 points 6 months ago (5 children)

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@sh.itjust.works 55 points 6 months ago (1 children)

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 6 points 6 months ago (3 children)

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@sh.itjust.works 10 points 6 months ago* (last edited 6 months ago) (2 children)

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 5 points 6 months ago

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

load more comments (1 replies)
[–] Takios@discuss.tchncs.de 8 points 6 months ago

I've seen that done for configuration management like Salt or Ansible. The repos for that were always hosted on internal Gitlab instances though.

load more comments (1 replies)
[–] JimmyMcGill@lemmy.world 15 points 6 months ago (1 children)

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.

[–] kambusha@sh.itjust.works 4 points 6 months ago (1 children)
[–] PumaStoleMyBluff@lemmy.world 10 points 6 months ago (3 children)

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.

load more comments (3 replies)
[–] andrew@lemmy.stuart.fun 6 points 6 months ago (3 children)

Better yet you can configure gitignore globally for git. I do this mostly to avoid polluting repo ignore files with my editor specific junk but *.key and similar can help prevent accidents.

https://git-scm.com/docs/gitignore

load more comments (3 replies)
[–] Nithanim@programming.dev 5 points 6 months ago

I never understood why everyone uses it as a ignore list. In my own and work repositories I always exclude everything by default and re-add stuff explicitly. I have had enough random crap checked in in the past by coworkers. Granted, the whole source folder is fully included but that has never been a problem.

load more comments (1 replies)
[–] NOT_RICK@lemmy.world 26 points 6 months ago (5 children)

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

[–] bamboo@lemmy.blahaj.zone 7 points 6 months ago (3 children)

Does Microsoft's GitHub offer any pre-receive hook configuration to reject commits pushed that contain private keys? Surely that would be a better feature to opt all users into rather than Windows Copilot.

[–] redcalcium@lemmy.institute 4 points 6 months ago* (last edited 6 months ago) (1 children)

They notify but iirc only if you push a commit to a public repo. The dev in the article pushed it to a private repo, then later made the repo public.

load more comments (1 replies)
load more comments (2 replies)
load more comments (4 replies)
[–] tal@lemmy.today 7 points 6 months ago (3 children)

Ehhh. I mean, I have local repositories that contain things that I wouldn't want to share with the world. Using git to manage files isn't equivalent to wanting to publish publicly on github.

I could imagine ways that private information could leak. Like, okay, say you have some local project, and you're committing notes in a text file to the project. It's local, so you don't need to sanitize it, can put any related information into the notes. Or maybe you have a utility script that does some multi-machine build, has credentials embedded in it. But then over time, you clean the thing up for release and forget that the material is in the git history, and ten years later, do an open-source release or something.

I do kind of think that there's an argument that someone should make a "lint"-type script to automatically run on GitHub pushes to try and sanity-check and maybe warn about someone pushing out material that maybe they don't want to be pushing to the world. It'll never be a 100% solution, but it could maybe catch some portion of leakage.

[–] Bookmeat@lemmy.world 16 points 6 months ago (2 children)

Users often don't take care to separate private and public environments. They just dump all their stuff into one and expect their brain to make the correct decision all the time.

Put your private data into a private space. Never put private data into a mixed use space or a public space.

e.g. Don't use your personal email at work. Don't use your personal phone for business. Don't put your passwords or crypto keys in the same github or gitlab account or even instance and don't reuse passwords and keys, etc.

load more comments (2 replies)
[–] fart_pickle@lemmy.world 14 points 6 months ago

Having plain text secrets, or having secrets at all in a repository is always a bad practice. Even if it's a super-duper private/local/no one will ever see this repo.

load more comments (1 replies)
[–] dhork@lemmy.world 124 points 6 months ago (2 children)

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 12 points 6 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 11 points 6 months ago (3 children)

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 21 points 6 months ago* (last edited 6 months ago)

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

load more comments (2 replies)
[–] Johanno@feddit.de 86 points 6 months ago (1 children)

They made 2 errors.

  1. Use crypto

  2. Storing the key anywhere close to the repo.

[–] FiniteBanjo@lemmy.today 14 points 6 months ago (2 children)
load more comments (2 replies)
[–] lowleveldata@programming.dev 82 points 6 months ago (4 children)

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 92 points 6 months ago* (last edited 6 months ago) (1 children)

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 9 points 6 months ago (1 children)

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...

load more comments (1 replies)
[–] partial_accumen@lemmy.world 59 points 6 months ago* (last edited 6 months ago) (3 children)

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.

[–] bigkahuna1986@lemmy.ml 15 points 6 months ago

You always mess up some mundane detail!

[–] acchariya@lemmy.world 4 points 6 months ago

It would have deposited the funds in an account "foobar123" and been lost forever

load more comments (1 replies)
[–] Theharpyeagle@lemmy.world 20 points 6 months ago

Oh yes absolutely, there are bots constantly crawling any open source code. A friend of mine accidentally leaked their discord API key, nuked a whole server within minutes.

[–] nucleative@lemmy.world 8 points 6 months ago

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

[–] Xantar@lemmy.dbzer0.com 74 points 6 months ago* (last edited 6 months ago) (2 children)

That's the kind of mistake you only make once.

[–] Sabata11792@ani.social 17 points 6 months ago (1 children)

I wouldn't survive that mistake.

[–] Xantar@lemmy.dbzer0.com 13 points 6 months ago (1 children)

Well, either you do it once :P

load more comments (1 replies)
load more comments (1 replies)
[–] k_rol@lemmy.ca 56 points 6 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.

[–] Bishma@discuss.tchncs.de 38 points 6 months ago* (last edited 6 months ago) (2 children)

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.

[–] barsquid@lemmy.world 9 points 6 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.

load more comments (1 replies)
[–] CriticalMiss@lemmy.world 20 points 6 months ago

There’s a reason we use .env files and put them in gitignore.

[–] JoMiran@lemmy.ml 11 points 6 months ago (1 children)

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.

[–] AbidanYre@lemmy.world 31 points 6 months ago (4 children)

That's the copy protection on dozens of computer games from the 90s.

[–] zarathustrad@lemmy.world 6 points 6 months ago

To get my codes you have to play Alone in the Dark 2, and have the original 2 sided playing cards, then translate that into Brittanic runes and find the latitude and longitude of the given city on a cloth map from the original Ulitma.

[–] JoMiran@lemmy.ml 5 points 6 months ago

Well, I am a Gen-X'r.

load more comments (2 replies)

What a muppet

[–] bear@slrpnk.net 6 points 6 months ago

Incredibly funny story, incredibly awful website.

load more comments
view more: next ›