我正在为我的教会建立一个数据库应用程序来处理一些相当敏感的数据..
应用程序是用ruby写在rails上的，
我们也希望用iPhone应用扩展它。
我目前正在尝试找到验证iPhone应用程序用户的最佳解决方案，这是我提出的一个解决方案：
iPhone应用程序发出握手请求（通过SSL），返回带有2个值的JSON字符串：api_key和api_secret。
任何后续请求都附加了2个额外的参数api_key和api_signature api_signature基本上是与用户电子邮件一起散列的api_secret来隐藏秘密。
rails应用程序通过将api_secret和用户电子邮件一起散列并将其与传入的签名进行比较来验证签名。
该应用获取数据： - ）
api_secret无效并每2小时重新创建一次（所以如果黑客抓住它，他们只有2小时的有效秘密......）
我认为这很聪明..我看到一个明显的场景：
如果黑客无论如何都掌握了api_key和api_signature怎么办..
如果他们将这些请求附加到他们的请求中，那么我的所有障碍是什么意思？
您如何更好地实施此目标？
非常感谢！
答案 0 :(得分：1)
我认为你的问题是静态签名。
如果你look at how AWS这样做（如果其他人已经做得好的话，我就是没有重新发明轮子的粉丝），他们的签名是从请求的所有参数中散列出来的，其中一个参数是被授权为时间戳。
这很重要，因为这意味着即使重复请求相同数据，签名也在快速变化。强制设置时间戳也意味着您可以确保请求的有效性相对较短，假设客户端和服务器上的时钟距离不是太远。我肯定不会长达2个小时 - 我会把窗户缩短到15分钟。
将其视为公钥和私钥。您可以发布公钥（api_key），但只有客户端和服务器才能知道私钥。
私钥不应该在请求中传输，并且传输它的静态哈希也不是很好 - 因此亚马逊采取的方法。
如果您确实需要将私钥传输到设备，我会觉得在与api_key相同的有效负载中传输私钥非常不舒服，但您现在可能应该从安全专家处获取建议，我超出了自己的范围，很高兴承认这一点。
答案 1 :(得分：0)
幸运的是，你的问题不是唯一的，所以没有必要重新发明任何东西。只需使用Digest access authentication即可。我对Ruby on Rails了解不多，但我知道有support for it。您也可以使用ASIHttpRequest为iPhone实现客户端实现，因此您不必发明任何安全方案。