API 密钥和秘密密钥如何工作?如果我必须将我的 API 和密钥传递给另一个应用程序，它会安全吗? [英] How do API Keys and Secret Keys work? Would it be secure if I have to pass my API and secret keys to another application?

问题描述

我刚刚开始思考 api 密钥和密钥是如何工作的.就在 2 天前，我注册了 Amazon S3 并安装了 S3Fox 插件.他们要求我提供访问密钥和秘密访问密钥，这两者都需要我登录才能访问.

I am just starting to think about how api keys and secret keys work. Just 2 days ago I signed up for Amazon S3 and installed the S3Fox Plugin. They asked me for both my Access Key and Secret Access Key, both of which require me to login to access.

所以我想知道，如果他们要我提供我的密钥，他们一定是把它存储在某个地方吧?这与询问我的信用卡号或密码并将其存储在他们自己的数据库中基本上不是一回事吗?

So I'm wondering, if they're asking me for my secret key, they must be storing it somewhere right? Isn't that basically the same thing as asking me for my credit card numbers or password and storing that in their own database?

密钥和 api 密钥应该如何工作?他们需要保密到什么程度?这些使用密钥的应用程序是否以某种方式存储它?

How are secret keys and api keys supposed to work? How secret do they need to be? Are these applications that use the secret keys storing it somehow?

推荐答案

基本上阐述了概述 这里.

它是这样工作的:假设我们有一个函数，它接受一个从 0 到 9 的数字，加上 3，如果结果大于 10，则减去 10.所以 f(2) = 5, f(8) = 1 等等.现在，我们可以创建另一个函数，称为 f'，它通过添加七个而不是三个来倒退.f'(5) = 2、f'(1) = 8 等

Here's how it works: let's say we have a function that takes a number from zero through nine, adds three and, if the result is greater than ten, subtracts ten. So f(2) = 5, f(8) = 1, etc. Now, we can make another function, call it f', that goes backwards, by adding seven instead of three. f'(5) = 2, f'(1) = 8, etc.

这是一个双向函数及其逆函数的示例.从理论上讲，任何将一件事映射到另一件事的数学函数都可以反转.但在实践中，您可以创建一个函数，将其输入打乱得非常好，以至于难以逆转.

That's an example of a two-way function and its inverse. Theoretically, any mathematical functions that maps one thing to another can be reversed. In practice, though, you can make a function that scrambles its input so well that it's incredibly difficult to reverse.

获取输入并应用单向函数称为散列"输入，亚马逊在其系统上存储的是您的密钥的散列".SHA1 就是这种单向"功能的一个例子，它还可以抵御攻击.

Taking an input and applying a one-way function is called "hashing" the input, and what Amazon stores on their system is a "hash" of your secret key. SHA1 is an example of this kind of "one-way" function, it's also hardened against attacks.

HMAC 函数建立在已建立的哈希函数的基础上，使用已知密钥来验证文本字符串.它的工作原理是这样的:

The HMAC function builds on established hash functions to use a known key to authenticate a string of text. It works like this:

• 您获取请求文本和密钥并应用 HMAC 函数.
• 您将该身份验证标头添加到您的请求中并将其发送到亚马逊.
• 亚马逊会查找他们的密钥副本以及您刚刚发送的文本并应用 HMAC 函数.
• 如果结果匹配，他们就知道您拥有相同的密钥.

这个和 PKI 的区别在于这个方法是 RESTful，允许最小数量的您的系统和亚马逊服务器之间的交换.

The difference between this and PKI is that this method is RESTful, allowing a minimum number of exchanges between your system and Amazon's servers.

这不是和询问我的信用卡号码或密码并将其存储在他们的自己的数据库?

Isn't that basically the same thing as asking me for my credit card numbers or password and storing that in their own database?

是的，尽管有人对 S3 造成的损害似乎仅限于耗尽您的帐户.

Yes, though the damage someone can do with S3 seems to be limited to draining your account.

他们需要保密到什么程度?是这些使用秘密的应用程序以某种方式存储它的密钥?

How secret do they need to be? Are these applications that use the secret keys storing it somehow?

在某些时候，您将不得不加载密钥，并且对于大多数基于 Unix 的系统，如果攻击者可以获得 root 访问权限，他们就可以获得密钥.如果你加密密钥，你必须有代码来解密它，并且在某些时候解密代码必须是纯文本以便它可以执行.这与 DRM 的问题相同，只是您拥有计算机.

At some point, you're going to have to load the secret key, and with most Unix based systems, if an attacker can get root access they can get the key. If you encrypt the key, you have to have code to decrypt it, and at some point the decryption code has to be plain text so it can be executed. This is the same problem DRM has, except that you own the computer.

在许多情况下，我只是将密钥放在权限有限的文件中，并采取通常的预防措施来防止我的系统被 root.有一些技巧可以让它在多用户系统中正常工作，例如避免使用临时文件等.

In many cases, I just put secret keys in a file with limited permissions, and take the usual precautions to prevent my system from being rooted. There are a few tricks to make it work properly with a multiuser system, such as avoiding temporary files and such.

这篇关于API 密钥和秘密密钥如何工作?如果我必须将我的 API 和密钥传递给另一个应用程序，它会安全吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！