这种用户身份验证方法的弱点是什么? [英] What are the weaknesses of this user authentication method?

问题描述

我正在开发自己的PHP框架.看来，我阅读过的所有安全文章都与我使用的用户身份验证方法大不相同，因此我可以使用一些帮助来发现安全漏洞.

一些在我开始之前可能有用的信息.我对我的MVC网址使用mod_rewrite.密码使用每个用户唯一的24个字符的盐进行加密. mysql_real_escape_string和/或所有类型的变量类型转换，以及所有出现的htmlspecialchars.

分步过程:

每页顶部:

session_start();
session_regenerate_id();

如果用户通过登录表单登录，则生成新的随机令牌以放入用户的MySQL行.哈希是根据用户的盐(首次注册时的盐)和新令牌生成的.将哈希和纯文本用户名存储在会话变量中，如果选中了记住我"，则将其复制到cookie中.

在每个页面上，检查cookie.如果设置了cookie，则将其值复制到会话变量中.然后将$ _SESSION ['name']和$ _SESSION ['hash']与MySQL数据库进行比较.销毁所有不匹配的cookie和会话变量，因此必须再次登录.

如果登录有效，则来自MySQL数据库的某些用户信息存储在一个数组中，以方便访问.到目前为止，我已经假定此数组是干净的，因此在限制用户访问权限时，我引用了user.rank，如果访问权限低于该页面的要求，则拒绝访问.

我已经尝试测试所有常见的攻击，例如XSS和CSRF，但也许我只是不足以入侵我自己的网站！我的系统似乎过于简单，以至于无法真正安全(安全代码只有100行).我想念什么?

对于从控制器调用函数，除SELECT查询之外，使用SELECT查询之外的任何内容都将需要$ _POST数据来确认删除.

我也花了很多时间来查找带有mysql_real_escape字符串的漏洞，但我没有发现任何最新信息(所有信息至少都是几年前的，而且显然已经得到修复).我所知道的是问题与编码有关.如果今天仍然存在该问题，我该如何避免呢?

我从某处借来的加密函数进行了修改:

public function encrypt($str, $salt = NULL) {
    if ($salt == NULL) $salt = substr(md5(uniqid(rand(), true)), 0, 24);
    else $salt = substr($salt, 0, 24);
    return $salt.sha1($salt.$str);
}

解决方案

帮个忙，并使用标准库来哈希密码.

由于安全性往往要比大多数程序员独自解决的复杂得多，并且具有更多看不见的破坏可能性，因此使用标准库几乎总是最简单，最安全(如果不是唯一的话)的可用选项.

标准库:
看一下:> 可移植的PHP密码哈希框架 : phpass ，并确保尽可能使用CRYPT_BLOWFISH算法.

使用phpass(v0.2)的代码示例:

require('PasswordHash.php');

$pwdHasher = new PasswordHash(8, FALSE);

// $hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );

// $hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
    echo 'password correct';
} else {
    echo 'wrong credentials';
}

PHPass已在一些众所周知的项目中实现:

• phpBB3
• WordPress 2.5+和bbPress
• Drupal 7版本(模块适用于Drupal 5和6)
• 其他

好处是，您不必担心细节，这些细节是由经验丰富的人编写的，并已由Internet上的许多人进行了审查.

无论您采取哪种方法，如果您选择"我会自己做，谢谢"的方法，请不要再使用MD5 .这是一个不错的哈希算法，但是出于安全目的完全被破坏了.

当前，最好将CRYPT_BLOWFISH与 crypt 一起使用.
PHP中的CRYPT_BLOWFISH是Bcrypt哈希的实现. Bcrypt基于Blowfish块密码，利用昂贵的密钥设置来减慢算法速度.

有关密码存储方案的更多信息，您还可以阅读 Jeff 的博客文章:您存储的密码可能不正确

I'm developing my own PHP framework. It seems all the security articles I have read use vastly different methods for user authentication than I do so I could use some help in finding security holes.

Some information that might be useful before I start. I use mod_rewrite for my MVC url's. Passwords are encrypted with 24 character salt unique to each user. mysql_real_escape_string and/or variable typecasting on everything going in, and htmlspecialchars on everything coming out.

Step-by step process:

Top of every page:

session_start();
session_regenerate_id();

If user logs in via login form, generate new random token to put in user's MySQL row. Hash is generated based on user's salt (from when they first registered) and the new token. Store the hash and plaintext username in session variables, and duplicate in cookies if 'Remember me' is checked.

On every page, check for cookies. If cookies set, copy their values into session variables. Then compare $_SESSION['name'] and $_SESSION['hash'] against MySQL database. Destroy all cookies and session variables if they don't match so they have to log in again.

If login is valid, some of the user's information from the MySQL database is stored in an array for easy access. So far, I've assumed that this array is clean so when limiting user access I refer to user.rank and deny access if it's below what's required for that page.

I've tried to test all the common attacks like XSS and CSRF, but maybe I'm just not good enough at hacking my own site! My system seems way too simple for it to actually be secure (the security code is only 100 lines long). What am I missing?

Edit: For calling functions from the controller, anything that uses anything other than SELECT queries will require $_POST data to confirm a delete, for example, in addition to the user rank requirements.

I've also spent alot of time searching for the vulnerabilities with mysql_real_escape string but I haven't found any information that is up-to-date (everything is from several years ago at least and has apparently been fixed). All I know is that the problem was something to do with encoding. If that problem still exists today, how can I avoid it?

The encrypt function I borrowed from somewhere and modified:

public function encrypt($str, $salt = NULL) {
    if ($salt == NULL) $salt = substr(md5(uniqid(rand(), true)), 0, 24);
    else $salt = substr($salt, 0, 24);
    return $salt.sha1($salt.$str);
}

解决方案

Do yourself a favour and use a standard library for hashing your passwords.

Because security tends to be a lot more complicated and with more invisible screw up possibilities than most programmers could tackle alone, using a standard library is almost always easiest and most secure (if not the only) available option.

The standard library:
Take a look at: Portable PHP password hashing framework: phpass and make sure you use the CRYPT_BLOWFISH algorithm if at all possible.

example of code using phpass (v0.2):

require('PasswordHash.php');

$pwdHasher = new PasswordHash(8, FALSE);

// $hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );

// $hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
    echo 'password correct';
} else {
    echo 'wrong credentials';
}

PHPass has been implemented in some quite well known projects:

• phpBB3
• WordPress 2.5+ as well as bbPress
• the Drupal 7 release, (module available for Drupal 5 & 6)
• others

The good thing is that you do not need to worry about the details, those details have been programmed by people with experience and reviewed by many folks on the internet.

Whatever you do if you go for the 'I'll do it myself, thank you' approach, do not use MD5 anymore. It is a nice hashing algorithm, but utterly broken for security purposes.

Currently, using crypt, with CRYPT_BLOWFISH is the best practice.
CRYPT_BLOWFISH in PHP is an implementation of the Bcrypt hash. Bcrypt is based on the Blowfish block cipher, making use of it's expensive key setup to slow the algorithm down.

For more information on password storage schemes, you could also read Jeff`s blog post about it: You're Probably Storing Passwords Incorrectly

这篇关于这种用户身份验证方法的弱点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！