这是一个好办法还是这个危险的呢？
如果没有错过理解,为了避免在中间的人,我可以将请求url添加到将被散列的变量,或者不是适当的方式
此外,我的大脑也陷入如何使用时间戳,以避免使用相同的数据对相同的URL进行大量请求.
如果我的问题被问了1000次,我很抱歉.然而,我已经读了一些文章,现在仍然不清楚我的小api有什么办法.
从我所看到的和理解的,这应该是方式.
>公钥存储在应用程序中,让用户或应用程序登录.
>服务器为访问该特定用户创建私钥.或者这应该永远是一个人还是由一个人创造的静态值？
>用户请求发送与请求一起签名是hash_hmac(一些值私有密钥);
>服务器检查这些值是否正确,并通过从发送的值创建相同的哈希值.
>如果服务器生成相同的哈希,则该请求是有效的,然后可以执行.
这是他们走的路吗,或者我在这里错过了一些市长的事情.
为了使数据是下面的方式创建哈希的好方法？
$l_sPrivateKey = 'something returned by database when user loged in';
$l_aData = array();
foreach($_POST as $key => $value){
if($key == 'signature') continue;
$l_aData[$key] = $value;
}
//This should then be the same as $_POST['signature'];
hash_hmac('sha256',serialize($l_aData),$l_sPrivateKey,false);
您的输入将不胜感激
提前问候和感谢
以下假设您的API是浏览器到服务器,因此JavaScript到PHP不是仅使用PHP的服务器到服务器. SRP将适用于两种情况,但下面的答案讨论了浏览器到服务器库.
使用Secure Remote Password协议来认证具有创建强会话密钥的副作用的API的用户.然后,您可以使用共享的强会话密钥来使用HMAC对API请求和响应进行签名.
RFC5054使用SRP而不是公钥来创建一个共享会话密钥来加密TLS流量.有一个implementation in OpenSSL.这表明SRP身份验证是一个绝对安全的替代公钥来创建一个安全的共享秘密.使用SRP的IMHO更方便解决您的问题.
Thinbus SRP库是一个JavaScript SRP库,具有对PHP服务器进行身份验证的演示. PHP演示程序不显示使用共享会话密钥,但只要在身份验证协议完成后,浏览器中的服务器和client.getSessionKey()就是$srp-> getSessionKey().默认的Thinbus配置会导致256bit的共享密钥.您可以使用HMAC参见下面的脚注1,了解如何使用签名的JSON.
怎么运行的
注册流程将是：
>客户端API注册表在客户端使用JavaScript生成不传输到服务器的随机API密码.这被保存到浏览器本地存储器中,并向用户显示要求他们将其打印并保留备份.
>密码给予Thinbus SRP客户端JS库代码,该代码输出客户端盐和密码验证器.
>将salt和验证器发布到服务器并保存在该客户端的数据库中.通常,Thinbus建议您使用HTTPS将验证者保留,以将验证者发送到服务器,以防止强力攻击恢复密码.如果您正在使用随机生成的密码,只要是典型的软件许可证密钥,那么您可以通过HTTP传输验证者.见下文脚注2.
API使用流程将从具有产生会话密钥副作用的客户端的SRP认证开始.请注意,所有这些都是在Thinbus演示代码中作为“标准用法”,但这里将说明STP认证如何工作的风格.该认证协议如thinbus page的序列图所示,并在线演示：
>客户端javascript从浏览器本地存储加载API密码.
>客户端AJAX从服务器中提取客户端盐和服务器随机一次数B.
>客户端javascript生成一次性号码A,然后使用密码,salt和两个一次性数字来生成会话密钥K,并使用两次号码进行散列,以创建密码证明M,将其发布到服务器及其随机A.
>服务器使用在注册时保存到数据库的密码验证器,客户端盐和两个随机数来计算会话密钥K,然后确认客户端发送密码证明M是好的.如果这一切都很好,它会向客户端发送自己的证明M2back.此时,客户端已经使用STP作为密码的zero-knowledge proof进行身份验证.
>客户端检查M2的计算.如果一切都好,双方都有一个共享秘密K,这是一个来自随机A和B的一次256位会话密钥,没有中间人可以知道.
>所有API请求和响应都可以通过HMAC与共享密钥签名并在另一方进行验证.
所有上述内容都在Thinbus的PHP演示中被覆盖,实际上调用$srp-> getSessionKey()在结尾有一个可以用于使用HMAC进行签名的键.
让SRP用密码的零知识证明来代替密码认证,这是令人惊讶的,并不是所有的开发人员都默认使用它.事实上,它也生成一个用于API签名的共享会话密钥,这是一个额外的好处.
脚注1：大多数API倾向于将一个JSON值发布到其中的所有数据.这是因为JSON是简单而强大的,内置了PHP和JavaScript中的API,可以将对象转换成字符串并重新启动.由于@dbrumann指出了一个注释,它是一个用于签署JWT的JSON的标准. Google建议这里是PHP和JavaScript两者的库.因此,如果您升级为传递一个JSON输入值,并为API中的每个命令返回一个JSON输出,您可以使用JWT库来签名并验证API的JSON输入和输出.其中一个JWS算法是“JWSAlgorithm.HS256 – 具有SHA-256的HMAC,256位密码”.图书馆将整理实际签名和验证的机制,因此您不必编写该代码并担心可能的安全漏洞.
脚注2：Thinbus的建议是通过HTTPS将密码验证器传输到服务器,以使验证者保密.这是为了防止对密码验证者的离线字典攻击,以恢复密码(即,密码被放入验证者,因此您需要通过验证者生成代码与用户盐运行16G crackstation password dictionary以找到匹配).使用API使用浏览器window.crypto API可以生成一个真正随机的“API密钥”.通常,Windows键是16个大写字母显示给格式为XXXX-XXXX-XXXX-XXXX的用户.检查GRC password search space page它说,一个随机的16字母大写密码大小将需要政府14年彻底搜索.鉴于这一估计,您可以安全地传输一个密码验证器,通过普通HTTP无需加密就可以生成这样一个长的随机密码的密码验证器,因为没有人可以通过验证器生成算法(其使用随机的方法)来运行多年的计算能力来运行这么多的密码猜测客户端盐不能预先计算)来找到匹配来恢复客户端API密码.
