Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub publishes DMCA deletion notifications sent by Bilibili

github.com

Post reply on HN
Print view View original

91–100 of 117 posts

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#91

Post by pavelbr »

dustinmoris wrote: post #36

Not great... MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1... Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1... More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1... This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1... And of course, RSA keys which they use for al…

I'm a new developer (an intern, actually). I just started writing a system that requires a couple secret strings. Currently I just have them as constants with my code, with the idea that I'll figure out something to do with them once I make sure everything is working.

What should I do with those secrets though? I'm not sure how to store them securely. So far I've been considering putting them in the server configuration so they can be read from environment variables, but that seems inconvenient for me and other developers and also not that much more secure.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#92

Post by dpark »

chrismeller wrote: post #86
tinus_hn wrote: post #83

Earlier quoted context omitted.

The choices are: 1. api key is publicly readable in a configuration files you ship 2. api key is compiled into the binary you ship. There is only obfuscation. Then again api keys are not security keys.

But literally in this case it was security keys. Even including an API key into the binary build is avoidable. Add an OAuth-style negotiation for the key as the first startup process. Start digging deeper and there are fewer and fewer reasons.

> Add an OAuth-style negotiation for the key as the first startup process.

How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret when you need clients to have access to it.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#93

Post by chrismeller »

dpark wrote: post #92
chrismeller wrote: post #86

Earlier quoted context omitted.

But literally in this case it was security keys. Even including an API key into the binary build is avoidable. Add an OAuth-style negotiation for the key as the first startup process. Start digging deeper and there are fewer and fewer reasons.

> Add an OAuth-style negotiation for the key as the first startup process. How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret wh…

Case in point: valid user credentials and it doesn’t matter what app is trying to authenticate. Issue a different key for every user (or every user per login or device) and your problem is solved.

Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#94

Post by farisjarrah »

pavelbr wrote: post #91
dustinmoris wrote: post #36

Not great... MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1... Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1... More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1... This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1... And of course, RSA keys which they use for al…

I'm a new developer (an intern, actually). I just started writing a system that requires a couple secret strings. Currently I just have them as constants with my code, with the idea that I'll figure out something to do with them once I make sure everything is working. What should I do with those secrets though? I'm not sure how to store them securely. So far I've been considering putting them in the server configurat…

How to handle organizational secrets is definitely your concern, however, you are probably too junior to be making decisions on implementing security best practices in production. Likely your company has methodologies in place to deal with deployment secrets. Ask a senior dev how they handle secret management. In many companies there are key management tools such as Hashicorp Vault or Ansible vault. Basically without knowing your environment its hard to tell you what to do, but there are lots of options out there, and your company may have already implemented some of them.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#95

Post by nickflood »

pavelbr wrote: post #91
dustinmoris wrote: post #36

Not great... MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1... Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1... More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1... This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1... And of course, RSA keys which they use for al…

I'm a new developer (an intern, actually). I just started writing a system that requires a couple secret strings. Currently I just have them as constants with my code, with the idea that I'll figure out something to do with them once I make sure everything is working. What should I do with those secrets though? I'm not sure how to store them securely. So far I've been considering putting them in the server configurat…

You read them from a config file and fill them into the config by hand while deploying. Never push secrets embedded into code or portions of the config file to your source repo.

You can hardcode the secrets to test stuff, but the first time you push the code to the repo should be the time you change it to reading from config. And add config to gitignore cause even if you don't stage the particular lines with the secrets in them, there will come one time where you'll rush or will have too long of a day when you'll push those secrets by accident. If you've got a public repo, then it's over. On a private repo then you may not notice this or not remember to remove it with a force push.

A point in time when you get tired of juggling config files manually in dev/prod is the point in time you explore the system for secret management and auto build/deployment as clearly your project has become useful/popular enough.

Those are my IMO and what I use as thresholds. Of course, if your environment is more relaxed there's no limit on further improving this practice.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#96

Post by dpark »

chrismeller wrote: post #93
dpark wrote: post #92

Earlier quoted context omitted.

> Add an OAuth-style negotiation for the key as the first startup process. How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret wh…

Case in point: valid user credentials and it doesn’t matter what app is trying to authenticate. Issue a different key for every user (or every user per login or device) and your problem is solved. Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...

OK, this depends on what you mean by an API key. If you are referring to a security token that identifies the user, then yes, you should always be creating a new key per user, and often per session.

However the term API key may also refer to an App key, intended to identify all users of a given app. The intention there is to be able to engage and widespread revocation or throttling in case an app is misbehaving or compromised. You cannot keep this sort of API key secret because it must be shared and must be available.

In the non-user device scenario you mentioned, I’m pretty sure you would actually be better off simply having the device generate a random GUID instead of going through a pointless negotiation to hand out a random GUID.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#97

Post by ksec »

dis-sys wrote: post #54

Sure, Bilibili's copyright must be respected, no question on that whatsoever. That being said, let's have a look on how this multi-billion company treats its programmers - flv.js is opened sourced by bilibili, it has 14,668 starts on github [1]. Bilibili paid the smart & hardworking programmer who single handedly started this project and made it popular $700 USD per month [2], there is a very long zhihu.com thread [2…

> $700 is about 10% of the fair market rate in China for skills like that.

So you are suggesting $7000 for skills like that? There are still countless PHP / Golang / Rails jobs going for under $2K. While I agree $700 is insanely low even if you are in some Tier 3 cities, I don't think 10% paint an accurate picture of the current state of Programming Paid in China.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#98

Post by kevin_thibedeau »

dustinmoris wrote: post #82
dustinmoris wrote: post #36

Not great... MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1... Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1... More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1... This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1... And of course, RSA keys which they use for al…

I don't know what to make of this, but this all feels like a deliberate attempt to damage this company. Here are some interesting things I noticed: - GitHub has a lot of DMCAs each month and going through them it seems that all repos have been taken down by GitHub, but in this case the entire source code is still online despite it being posted here on HN for hours now and after they have been notified. - None of the…

The only sad thing here is a fraudulent DMCA takedown for a trademark violation.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#99

Post by bmm6o »

colejohnson66 wrote: post #88
heavenlyblue wrote: post #85

Earlier quoted context omitted.

>> you find that everyone is hard coding secrets in code and standing up some secrets infrastructure would take weeks to get right. You open up the code, find all of the secrets (e.g. using high-entropy substring search), replace them with access to a global variable, and set it from a file set by a configuration from a command line. Done.

And when your manager says don’t do that because it’s a waste of time?

If you aren't allowed to do it right, I'm not sure what kind of advice will be useful.

Re: GitHub publishes DMCA deletion notifications sent by Bilibili

#100

Post by GoblinSlayer »

dustinmoris wrote: post #82
dustinmoris wrote: post #36

Not great... MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1... Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1... More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1... This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1... And of course, RSA keys which they use for al…

I don't know what to make of this, but this all feels like a deliberate attempt to damage this company. Here are some interesting things I noticed: - GitHub has a lot of DMCAs each month and going through them it seems that all repos have been taken down by GitHub, but in this case the entire source code is still online despite it being posted here on HN for hours now and after they have been notified. - None of the…

What harm? It's nice to have the source.
Post reply on HN