@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 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.
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.
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.
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.
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)
The value of this video doesn’t match the views! Thank you so much for this!
Totally!
Thank you - tell your friends :)
Good practical ideas regarding the API keys! I appreciate an API key check schema at the end of presentation! Very informative!
Thanks!
Just...wow! Thank you so much for this video. It clarifies everything I had a question for.
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 insights are so informative and useful. Thanks ☺
Excellent video. Thank you!
You are welcome!
Interesting insights! Thanks for making this video ❤
My pleasure!
Great talk. Thanks!
Thank you for watching!
@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 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
Excellent tips, thanks!
\o/
Fanx was difficult to find info about this
Glad you found it helpful!
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.
Good video, big thanks!
Glad you liked it!
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!
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.
How can I make use of api key for authorization
Follow this guide and setup a gateway, consider using Zuplo: zuplo.com
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.
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.
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)