设置api密钥_我应该将我的API密钥设置多长时间?

文章讨论了如何确定API密钥的长度以确保唯一性,通过计算哈希值的冲突概率来避免重复。作者指出,不必使用过长的哈希,而是应该基于项目的预期需求和生命周期来合理计算所需长度。例如,对于可能需要生成10,000个值的项目,使用3位长度的哈希可能导致冲突,而10位长度的哈希则可将冲突概率降低到极低水平。" 125396598,7594839,Spark本地环境连接云HDFS实战:解决BlockMissingException问题,"['Spark开发', 'Hadoop', '云存储', '数据读取', '问题解决']
摘要由CSDN通过智能技术生成

设置api密钥

by Sam Corcos

由Sam Corcos

我应该将我的API密钥设置多长时间? (How Long Should I Make My API Key?)

计算散列值的冲突概率 (Calculating collision probabilities of hashed values)

Say you built an API that generates public keys, and these keys all need to be unique and hard to guess. The most common way to do this is to use a hash function to generate a random series of numbers and letters. A typical hash looks something like the text below.

假设您构建了一个可生成公共密钥的API,那么这些密钥都必须是唯一的且难以猜测。 最常见的方法是使用哈希函数生成随机的数字和字母系列。 典型的哈希看起来像下面的文本。

AFGG2piXh0ht6dmXUxqv4nA1PU120r0yMAQhuc13i8

AFGG2piXh0ht6dmXUxqv4nA1PU120r0yMAQhuc13i8

A question that often comes up is, “How long does my hash need to be in order to ensure uniqueness?” Most people assume this is a difficult calculation. So they default to some very large number, like a 50-digit hash. The equation to approximate collision probability is actually quite simple.

经常出现的一个问题是:“为了确保唯一性,我的哈希需要多长时间?” 大多数人认为这是一个困难的计算。 因此,它们默认使用非常大的数字,例如50位哈希。 近似碰撞概率的方程实际上很简单。

我该如何计算? (How do I calculate?)

Let’s assume you’re using a good cryptographic algorithm (i.e. not JavaScript’s Math.random). Every language has a decent crypto package for generating random hashes. With Phoenix, you can use the Erlang :crypto package.

假设您使用的是好的加密算法(即不是JavaScript的Math.random )。 每种语言都有一个不错的加密软件包,用于生成随机哈希。 使用Phoenix,您可以使用Erlang :crypto包。

There are only two pieces of information you need to do the calculation:

您只需要执行两条信息即可进行计算:

  1. How many possible unique hash values can you create with the given inputs? We’ll assign this to the variable N.

    您可以使用给定的输入创建多少个唯一的哈希值? 我们将其分配给变量N。

  2. How many values could you possibly need to generate in the lifetime of your project? We’ll assign this to the variable k.

    在您的项目生命周期中,您可能需要生成多少个值? 我们将其分配给变量k。

To calculate the first value, add up all the possible characters that can go into your hash. Raise it to the power of the length of your hash.

要计算第一个值,请将所有可能包含在哈希中的字符加起来。 将其提高到哈希长度的力量。

So for example, if your hash value contains numbers, lowercase, and uppercase letters, that adds up to 62 total characters (10 + 26 + 26) that we can use. If we are generating a hash of only 3 characters in length, then:

因此,例如,如果您的哈希值包含数字,小写字母和大写字母,则总共可以使用62个字符(10 + 26 + 26)。 如果我们生成的长度仅为3个字符的哈希,则:

N = 62³ = 238,328 possible values

N =62³= 238,328可能的值

To calculate the second value, you need to think about what your app does and make some reasonable assumptions.

要计算第二个值,您需要考虑您的应用程序的功能并做出一些合理的假设。

Let’s say your app is generating a hash to assign to each of your customers. Let’s also say that your app is very niche. The absolute-best case scenario, your app will have 1000 customers over its lifetime. Then, for safety’s sake, we’ll multiply that by 10. We assume that you may need to generate 10,000 values over the course of your app’s life.

假设您的应用正在生成哈希以分配给每个客户。 我们还说您的应用程序非常利基。 在绝对最佳的情况下,您的应用在整个生命周期内将拥有1000个客户。 然后,为了安全起见,我们将其乘以10。我们假设您可能需要在应用的生命周期内生成10,000个值。

k = 10,000 upper bound for possible values that need to be created

k = 10,000需要创建的可能值的上限

So now we need to calculate. There are many algorithms we can use. We’ll use one of the simple approximations, where e is the mathematical constant (the base of the natural log), and k and N are the same values as above.

所以现在我们需要计算。 我们可以使用许多算法。 我们将使用一种简单的近似值 ,其中e是数学常数(自然对数的底数),而kN是与上述相同的值。

The base equation gives us the probability that all values are unique. Then we subtract that result from 1 to get the odds that you have a collision. If you don’t feel like writing your own equation, I’ve provided one below written in JavaScript.

基本方程式为我们提供了所有值都是唯一的概率。 然后,我们从1中减去该结果即可得出发生碰撞的几率。 如果您不想编写自己的方程式,请在下面提供用JavaScript编写的方程式。

So in the example above, calculate(N, k) yields a probability of approximately 100% that you will have a collision. So for that use case, you should use a hash of more than 3 characters in length.

因此,在上面的示例中, calculate(N,k)会产生大约100%的碰撞概率。 因此,对于该用例,应使用长度超过3个字符的哈希。

Now, if we were to take that same example but change the length of our hash from 3 to 5, we would get an N that is much larger (exponentials are good like that).

现在,如果我们采取同样的例子,但改变了我们从3哈希的长度为5,我们会得到一个N大得多 (指数都是这样的好)。

N = 62⁵ = ~900,000,000

N =62⁵=〜9亿

Assuming the same value k, our new probability of a collision is down to only 5.4%. What if we bumped that from 5 characters to 10?

假设值k相同,则我们发生碰撞的新概率仅为5.4% 。 如果我们将字符数从5个增加到10个怎么办?

N = 62¹⁰ = ~800,000,000,000,000,000

N =62¹⁰=〜800,000,000,000,000,000

Yes, that’s ~800 quintillion unique hashes. Which bring your odds of a collision down to 0.000000000062%. This is about a 1-in-50-billion chance that you have a conflict. And that’s with a hash of 10 digits — something like: BwQ1W6soXk.

是的,这是约800亿个独特的哈希值。 这使您的碰撞几率降至0.000000000062%。 这大约有500亿分之一的机会发生冲突。 这是10位数字的哈希-类似于:BwQ1W6soXk。

For another example, let’s say you’re a data processing company that deals with lots of transactions. We’ll say you deal with 1 million processes per second and you need to generate a hash for each of them. Let’s also say that you think this company could run for the next 100 years.

再举一个例子,假设您是一家处理大量交易的数据处理公司。 我们将说您每秒处理一百万个进程,并且需要为每个进程生成一个哈希。 假设您认为这家公司可以在未来100年经营。

k = ~3,000,000,000,000,000

k = 〜3,000,000,000,000,000

That comes out to about 3 quadrillion hashes that you need made that all need to be unique. That’s a lot of data! But even with this extremely large number to work with, you only need a 21-digit hash to ensure a 1-in-10-million chance of collision over the lifetime of the project.

这样就得出了大约3个需要满足所有要求的唯一性的四方哈希。 大量的数据! 但是,即使可以处理的数目如此之大,您也只需要使用21位数字的哈希值,就可以确保在项目生命周期中发生碰撞的可能性达到了十分之一。

So the next time you’re worried about the length of your hash in ensuring uniqueness, know that you don’t need one as long as you think you do. Plus, you can do the calculation yourself without much effort.

因此,下次您担心确保唯一性时哈希值的长度时,请知道您不需要的时间就与您认为的一样长。 另外,您可以自己进行计算,而无需花费太多精力。

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.

Sam Corcos是Sightline Maps (用于3D打印地形图的最直观的平台)以及LearnPhoenix.io (用于使用Phoenix和React构建可扩展的生产应用程序的中级高级教程网站)的首席开发人员和共同创始人。

翻译自: https://www.freecodecamp.org/news/how-long-should-i-make-my-api-key-833ebf2dc26f/

设置api密钥

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值