基于REST的API的安全性

我一直在寻找技术来保护在android/iphone应用程序或网站应用程序中使用的API。
我发现了一种我喜欢的技术，但不确定它是否是好的或者什么是错的（除了是一个长时间的过程）。
基于REST的API的安全性

处理（用户侧最初）：
首先一个盐通过散列用户口令创建的。
然后通过散列请求的URL（通过查询字符串在末尾附加用户名）和salt来创建签名。
最后，通过散列用户名和签名来创建令牌。
令牌在标头内传递给服务器（每次）。

第一请求：
第一个请求必须是验证端点并包括DEVICE_ID作为查询字符串。
在服务器上完成相同的处理（如上所述），并且如果令牌与用户发送的令牌相匹配，则将device_id存储在数据库中，并将其分配给该用户名以供将来参考（设备ID在请求中找到网址），并在此后用于验证用户名/设备。

所有后续请求：
在用户端和服务器端现在为每个请求与令牌是不同的，每次（如所请求的URL变化）的处理必须发生。
未包含代码，因为尚未编写代码。

来源

2013-01-15 Craig Taub

你不这样做，你创建与盐散列，而不是“通过散列创造盐”。 –

@JakubKonecki好点猜测盐应该是一个'盐'，然后用密码散列。 –

“salt”只是在散列字符串之前由服务器向密码添加的一串秘密随机字节。它可以防止相同的密码（例如'passw0rd'）在任何地方产生相同的散列结果。这可以防止黑客使用彩虹表将密码反转回密码。尽可能让你的盐尽量模糊，你甚至可以为每个用户名使用不同的salt值（但不要把它作为用户名，这太明显了）。 –

您的身份验证模型是共享的秘密身份验证。在你的情况下，你的用户密码充当共享密钥。你需要确保你有一个安全的方式提前获得密码给用户和服务器。为了签署请求，您可以创建一条包含所有请求标头和数据的消息。然后散列该请求。然后该散列（令牌）将与请求一起传递。服务器将在服务器上执行相同的签名和散列处理，并确保令牌匹配。

在你的榜样你的声音就像你要创建这个伪码令牌：

Token = hmac-sha1(Hash(Pasword + Salt) + RequestUrl + UserName)

你的方式是不坏，但我想你的方法比较亚马逊的REST验证模型和实施更紧密的版本他们详细描述了什么。 http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

及其履行情况：

"Authorization: AWS " + AWSAccessKeyId + ":" + base64(hmac-sha1(VERB + "\n" 
           + CONTENT-MD5 + "\n" 
           + CONTENT-TYPE + "\n" 
           + DATE + "\n" 
           + CanonicalizedAmzHeaders + "\n" 
           + CanonicalizedResource))

他们对包括已经离开了，包括但不限于某些领域很好的理由：

时间戳是防止重放攻击。
内容-MD5是防止防止人与请求篡改数据（相关 POST并提出）

来源

2013-01-15 14:51:41 kampsj

非常好。另外，如果您需要更简单的方法，则可以通过SSL（HTTPS）连接使用基本或摘要HTTP标准身份验证。 – miguelcobain

基于REST的API的安全性

回答

相关问题