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

[docs] Explain concepts and cryptography for API key construction #1065

Open
fungs opened this issue Feb 28, 2024 · 3 comments
Open

[docs] Explain concepts and cryptography for API key construction #1065

fungs opened this issue Feb 28, 2024 · 3 comments
Labels
Documentation Improvements or additions to documentation

Comments

@fungs
Copy link

fungs commented Feb 28, 2024

Type of documentation issue

Missing Information

Describe the problem and the proposed solution

Unkey is great software that fills a need!

I've read the current docs, and they are pretty comprehensive when it comes to usage. But for the security architecture I only see the statement, that API keys are checked using their hashes. Without digging into the source code, I can't answer fundamental questions like:

  • how is the API key itself generated, and what is the encoding format?
  • is there any data "wrapped" (encoded) in the string itself, or is it just random?
  • are API keys cryptographically signed?
  • are API keys intrinsically linked to and API?

Related questions are:

  • where is "wrapped" data stored?
  • is "wrapped" data considered to be private (to whom)?

I noted that keys can be unwrapped by anyone without authentication using the public unkey API (which also seems to count against the API call limits, so a malicious customer could easily consume the API calls in an endless while-curl-loop, but that's a different topic). Due to this fact, I assume that wrapped data is considered public. That's however important, as the data can be used for authorization and should then not contain data which should not be visible to end users.

Just my two cents: I think a little cryptography, like real root keys and signing in the cryptographic sense, could make the whole architecture more robust and secure. But for judging, I'd need to understand the very basics asked here.

@fungs fungs added Documentation Improvements or additions to documentation Needs Approval Needs approval from Unkey labels Feb 28, 2024
Copy link

linear bot commented Feb 28, 2024

@chronark chronark removed the Needs Approval Needs approval from Unkey label Feb 29, 2024
@chronark
Copy link
Collaborator

Good point, we should expand the docs!

Before we do, what do you mean by "wrapped" data?


and regarding this:

so a malicious customer could easily consume the API calls in an endless while-curl-loop

yes they could and we are working to migrate towards preventing this, but a malicious customer could also take that same key and just spam requests against your API endpoint, which would result in the same outcome.

other than requiring a 2nd factor (apiId or ideally root key), we're also building out a system to detect abuse to alert you and you can disable the key manually or potentially automatically

@fungs
Copy link
Author

fungs commented Feb 29, 2024

Before we do, what do you mean by "wrapped" data?

I was referring to the phrase "unwrap the data" somewhere in the documentation, which might be misleading, because it suggests that the associated metadata including owner and role are somehow encoded in the data?

but a malicious customer could also take that same key and just spam requests against your API endpoint, which would result in the same outcome

My API is under my control and I could easily take precautions against such actions, like first level rate limitation, exponential time penalties, firewall blocking etc.

@chronark chronark removed the Documentation Improvements or additions to documentation label Jun 28, 2024
@perkinsjr perkinsjr added the Documentation Improvements or additions to documentation label Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants