我为 PHP 网站制作 API,我需要以加密形式发送登录名和用户密码。我选择了以下方法进行解密:
$decrypted = openssl_decrypt($user_login, 'bf-ecb', $client_id);
$user_login
像 a 这样的字符串在哪里'login:password'
?了解我的$client_id
站点和客户端应用程序。客户端很可能是 iPhone 上的应用程序。我选择的加密算法是正常的吗,用户名和密码的编码在客户端不会有问题吗?
我为 PHP 网站制作 API,我需要以加密形式发送登录名和用户密码。我选择了以下方法进行解密:
$decrypted = openssl_decrypt($user_login, 'bf-ecb', $client_id);
$user_login
像 a 这样的字符串在哪里'login:password'
?了解我的$client_id
站点和客户端应用程序。客户端很可能是 iPhone 上的应用程序。我选择的加密算法是正常的吗,用户名和密码的编码在客户端不会有问题吗?
我选择的加密算法是正常的吗,用户名和密码的编码在客户端不会有问题吗?
您可能需要使用WebCrypto 之类的东西来确保客户端可以使用接受和实施的加密算法。您可能需要对其进行填充。
从更大的角度来看,您有两个问题需要解决。首先是网络安全模型。在 Web 安全模型中,拦截是一个有效的用例。二是违反服务器安全和密码列表。
拦截
第一个问题是由于 W3C 的理念造成的,对于破碎的愿景,您无能为力。Web 安全模型的基本缺陷在Public Key Pinning with Overrides中变得非常清晰。覆盖适应了拦截,网络人努力淡化和掩盖这种行为。
您的直接防御是像您一样设置额外的安全控制。也就是说,使用加密使入侵者无法使用用户名和纯文本密码。WebCrypto应该可以帮助你,所以你不需要填充它。
但是,有一个潜在的问题。拦截器可以允许加密的用户名和密码通过,然后在返回给客户端时捕获cookie或令牌。所以你也需要保护cookie。
并且需要保护用户名、密码和 cookie 免受重放攻击。您不希望攻击者获取加密的用户名和密码,然后在稍后重放它以获得经过身份验证的会话。所以听起来它也需要盐或随机数。
数据泄露
第二个问题可以通过遵循服务器端密码存储的最佳实践来解决。为此,请参阅 OWASP 的密码存储备忘单和安全密码存储威胁模型