如何在最终用户浏览器的api调用中保护合作伙伴凭据

时间:2018-08-02 13:42:30

标签: java encryption password-encryption

团队,

我有一个要求,例如我必须支持我的合作伙伴(第三方)门户网站,以便通过使用来自他们浏览器的凭据进行api调用来直接致电我们。

e.g.) Partner portal browser makes AJAX Call with below:

      URL      ---> https://example.com/request
      HEADER   ---> user_id   : foo
      HEADER   ---> password  : mypasswd
      payload  ---> {
                       "request_time" : 2232876435,
                       "request_name" : "get_user_info",
                       ...
                       ...
                    }

他们的浏览器/门户可供不信任的用户访问/使用。现在的问题是,因为呼叫来自前端;最终用户可以轻松地检查浏览器,以查看网络api调用以及我们提供给合作伙伴以在我们这边进行授权的凭据。

因此,我正计划通过要求合作伙伴在其 Portal后端服务器中加密有效负载和标头并向其提供门户中的加密信息的方式来向合作伙伴提出建议。

Encrypt (payload)   using mypasswd.
Encrypt (password)  using request_time  <NOW OPTIONAL TO PASS>

现在,

e.g.) URL      ---> https://example.com/request
      HEADER   ---> user_name : foo
      HEADER   ---> password  : ENCRYPTED<mypasswd>  <-- OPTIONAL
      payload  ---> ENCRYPTED< 
                       {
                       "request_time" : 2232876435,
                       "request_name" : "get_user_info",
                       ...
                       ...
                       } 
                    >

因此,在我们的系统中,我们将使用为user_id mypasswd检索的foo解密有效负载。因此,如果解密成功,则请求来自有效资源。

现在最终门户用户无法理解浏览器检查的请求。

注意:

  1. 我不能建议我的伴侣从他们的后端打电话。
  2. 从请求有效载荷中,我可以通过唯一的事务ID识别重复的相同请求,因此他们无法重新提交相同的请求。因此避免了重放攻击。

问题:

Q1)此解决方案有任何缺陷或建议吗?
Q2)在Java中是否可以使用密码来识别解密是否成功?我是加密技术的新手,所以能否请您分享任何代码或链接来实现这一目标?

您的想法对我来说很有价值。



TLDR:

参考文献:

基本加密详细信息

https://blog.storagecraft.com/5-common-encryption-algorithms/

https://www.veracode.com/blog/research/encryption-and-decryption-java-cryptography

https://gooroo.io/GoorooTHINK/Article/13023/The-difference-between-encryption-hashing-and-salting/2085#.W2L_KdgzZD0

Java加密

How to encrypt and decrypt String with my passphrase in Java (Pc not mobile platform)?

Java Security: Illegal key size or default parameters?

通过此异常识别解密成功:

Given final block not properly padded

1 个答案:

答案 0 :(得分:1)

编辑:我误解了这个问题。如果信息在到达终端用户之前被 之前的第三方加密,则这种方法通常是安全的。重播攻击是要注意的主要内容。如果发出的请求是幂等的,那么您实际上就不必担心,但是否则,您可能需要为使用过的令牌实现一个短暂的数据库,以及到期时间或类似条件。


您正在以错误的方式解决此问题。让最终用户代表第三方向您发出此请求很愚蠢-如果请求来自他们的浏览器,那么根据定义,他们可以控制发送信息的方式和发送方式。加密无济于事,因为加密逻辑也是客户端。

此问题的解决方案是消除最终用户。该请求应直接来自第三方。这可能是最终用户向第三方API发出的请求,也可能不是—没关系。