I use bcrypt for one way encrypted key. {retrievable_part}.{irretrievable_part} Separated with dot. You can do a script to select in full with a single click. Brcrypt is not that fast but not that slow to be an issue. Caching in memory requires extra work to do.. if your database comnector supports query caching, use that instead.
Yes, this is something that would happen on every request so must developers prefer something a bit faster than bcrypt but probably not making a measurable difference in most cases. BCrypt is often used in password checks which aren't on every request, as a password is often exchanged for some temp token.
hey I'm having a hard time undertanding how to set up my api key store since I have an API gateway in front of my application. Do I need to register the API key in the gateway as well as in the application DB? (I'm using gcp api gateway for context, and they offer a api key validation in the gateway, but I aso want to fetch data from the entity linked to this key)
I don't think GCP API Gateway supports API Key authentication - in that case, you might want to look at an alternative - may I recommend Zuplo (zuplo.com) which has it built in.
It should be treated as a password. Meaning securely sent to customers if they are using them to access your application, or hashed if you are storing them in your own database.
Agree with @CC-tf1wq here. At some level, even mTLS certificates and clientID/clientSecrets are (encodable as) plaintext passwords. It's not necessarily a bad thing but there are something things you should do to reduce risk: support self serve rolling, support key revocation, support github secret scanning. Naturally we do all this for you at Zuplo.com if you use our solution too.
This is a best practices guide vs how to code guide. But most people shouldn't build this themselves and should use a service or gateway (We'd recommend zuplo.com obviously)
@20:40 you can actually triple click in most input fields to select the entire value, or set a select on entry on a field so the entire contents is selected. Also adding a copy button makes this a moot point as well.
Can’t guarantee that other input boxes that the key may be in will have an copy button. Most people don’t know about triple click and so will struggle. It’s zero cost to solve these with a bit of thoughtful design. You do you though.
I think your argument, if it is good enough for stripe then it should be good enough for you is greatly misleading. You have to account for the threat model. I’m sure the companies that use api keys have put that extra effort to secure the ecosystem. I always advocate for more security over ease of use…typically, things that have been made easier to use have hidden complexities so unless those hidden complexities are understood and accounted for the implementation could be at risk. But also, I’m not advocating for JWT, there are better solutions. But in this scenario, JWT vs API Key, JWT. :-)
We give some reasons why we think some elements of API keys are more secure than OAuth JWT and API Keys clearly simpler from both an implementation and adoption standard (given your point about complexity) - the main reason people might question the approach is that it's not standardized and so some of the best practices are not well documented. This video is an effort to change that. As always, you should do what you think is best for your scenario.
There are professional tools to do store your keys from multiple providers, and lots of folks use password managers (e.g. 1password) which has vaults and items designed for assets like this.
Good practical ideas regarding the API keys! I appreciate an API key check schema at the end of presentation! Very informative!
Thanks!
this is a very, very good video. I would watch a whole series on diff dev topics if they were presented this way. Many thanks!
The value of this video doesn’t match the views! Thank you so much for this!
Totally!
Thank you - tell your friends :)
Interesting insights! Thanks for making this video ❤
My pleasure!
I use bcrypt for one way encrypted key.
{retrievable_part}.{irretrievable_part}
Separated with dot. You can do a script to select in full with a single click.
Brcrypt is not that fast but not that slow to be an issue.
Caching in memory requires extra work to do.. if your database comnector supports query caching, use that instead.
Yes, this is something that would happen on every request so must developers prefer something a bit faster than bcrypt but probably not making a measurable difference in most cases. BCrypt is often used in password checks which aren't on every request, as a password is often exchanged for some temp token.
Great insights - thanks for the video. Quick question, how would you recommend generating the checksum?
You can use an algorithm like CRC32 then convert to base16. Lots of suitable approaches.
@@Zuplo Awesome - thanks! I'll start there and continue exploring other approaches
Great talk. Thanks!
Thank you for watching!
hey I'm having a hard time undertanding how to set up my api key store since I have an API gateway in front of my application.
Do I need to register the API key in the gateway as well as in the application DB? (I'm using gcp api gateway for context, and they offer a api key validation in the gateway, but I aso want to fetch data from the entity linked to this key)
I don't think GCP API Gateway supports API Key authentication - in that case, you might want to look at an alternative - may I recommend Zuplo (zuplo.com) which has it built in.
Thanks for sharing! Sounds logic. In your experience, how about versioning of the API / End Points, any thoughts about it that you can share?
Yes, going to make a deep dive video on this - coming soon! Subscribe!
Good video, big thanks!
Glad you liked it!
How a retrievable api key is not a glorified plaintext password?
It should be treated as a password. Meaning securely sent to customers if they are using them to access your application, or hashed if you are storing them in your own database.
Agree with @CC-tf1wq here. At some level, even mTLS certificates and clientID/clientSecrets are (encodable as) plaintext passwords. It's not necessarily a bad thing but there are something things you should do to reduce risk: support self serve rolling, support key revocation, support github secret scanning. Naturally we do all this for you at Zuplo.com if you use our solution too.
and sample code?
This is a best practices guide vs how to code guide. But most people shouldn't build this themselves and should use a service or gateway (We'd recommend zuplo.com obviously)
Just...wow! Thank you so much for this video. It clarifies everything I had a question for.
Excellent video. Thank you!
You are welcome!
@20:40 you can actually triple click in most input fields to select the entire value, or set a select on entry on a field so the entire contents is selected. Also adding a copy button makes this a moot point as well.
Can’t guarantee that other input boxes that the key may be in will have an copy button. Most people don’t know about triple click and so will struggle. It’s zero cost to solve these with a bit of thoughtful design. You do you though.
How can I make use of api key for authorization
Follow this guide and setup a gateway, consider using Zuplo: zuplo.com
Fanx was difficult to find info about this
Glad you found it helpful!
The insights are so informative and useful. Thanks ☺
I think your argument, if it is good enough for stripe then it should be good enough for you is greatly misleading. You have to account for the threat model. I’m sure the companies that use api keys have put that extra effort to secure the ecosystem. I always advocate for more security over ease of use…typically, things that have been made easier to use have hidden complexities so unless those hidden complexities are understood and accounted for the implementation could be at risk.
But also, I’m not advocating for JWT, there are better solutions. But in this scenario, JWT vs API Key, JWT. :-)
We give some reasons why we think some elements of API keys are more secure than OAuth JWT and API Keys clearly simpler from both an implementation and adoption standard (given your point about complexity) - the main reason people might question the approach is that it's not standardized and so some of the best practices are not well documented. This video is an effort to change that. As always, you should do what you think is best for your scenario.
As a person who uses the notes app to store api keys, how do you make a vault? Also great video, it helped a lot!
There are professional tools to do store your keys from multiple providers, and lots of folks use password managers (e.g. 1password) which has vaults and items designed for assets like this.
Excellent tips, thanks!
\o/