我有一个使用简单用户名/密码登录方案的小型网络应用程序。 我注意到有几次用户在正确输入密码时不允许用户登录。
该代码最初只是在初始注册时加密用户输入的密码，如下所示：
function encode5t($str) {
for($i=0; $i<5;$i++) {
$str=strrev(base64_encode($str)); //apply base64 first and then reverse the string
}
return $str;
}
$password=mysql_real_escape_string($_POST['password']);
$pass=encode5t($password);
然后将$pass插入到 MySQL 数据库中。然后使用相同的函数来在登录时加密密码，并根据数据库进行检查，如下所示：
$username = $_POST['username'];
$psw = $_POST['password'];
$npsw=encode5t($psw);
$query = sprintf("SELECT * FROM members WHERE username='%s' AND password='%s'",
mysql_real_escape_string($username),
mysql_real_escape_string($npsw));
根据密码输入表单的方式，会出现此问题。如果只是输入密码，则没有问题，但如果将密码复制/粘贴到表单中（例如从包含新生成的密码的电子邮件中），则会失败。加密功能创建完全不同的哈希并且不匹配，因此用户未登录。
我已经玩过编码并将其更改为仅使用 md5（），但我得到相同的结局结果 - 剪切/粘贴产生的哈希值与简单地在表单中键入密码产生的哈希值不同。
页面编码中是否有某些内容会使复制/粘贴文本与键入的文本不同？
问题是，当用户粘贴用户名/密码时，它之前或之后通常有空格。 通过trim()运行这些字段来解决此问题。
另一方面，您拥有的东西并不是那么安全。 你的 base64 字符串不会欺骗任何人很长时间，并且 md5 不应该用于密码哈希，尤其是在没有加盐的情况下。 尝试一些更强大的东西，比如漩涡。 最后，我建议将准备好的查询与 PDO 一起使用以避免注入问题。 您目前正在转义您的数据...真棒！ 但是，最好不要冒险错过某个地方的逃生机会。