Концепция игрового сайта

[Jackky]

Автор оригинала: Wicked
1) http://www.google.ru/search?q=21232f297a57a5a743894a0e4a801fc3
2) http://ru.wikipedia.org/wiki/Радужная_таблица

Интереесно, но я думаю, что все хэши гугл не найдет, а насчет радужной таблицы... почитал начало, но не очень понял принцип ее работы (не быть мне хацкером). Вот подумал, что, если в поле pass добавлять примерно следущее:

$pass = md5($pass.$login);

И хранить в поле пароля зашешированое значение ЛогинПароль, а при входе на сайт, соответственно сверять хэш из таблицы с хэшем введенных $login.$pass, а если они не будут совпадать, то сообщать пользователю таинственную фразу, что "Вы ввели неверный логин и/или пароль.". Тогда в поле pass получается зашэшированный пароль из 12+ символов, явно отличный от qwerty-подобных. Тогда и гугл молчать будет, а подборщики сплавятся прежде, чем подберут. Или я не прав? А не будет ли это нагружать сервер?

 

[Духовность™]

да, это нормальный спооб

 

[Фанат]

Слишком много разговоров на такую мизерную задачу.

собственно так оно и есть

Именно так и есть? И дело кончится тем, что ты поставишь готовую бесплатную галерею с голосованием?

-~{}~ 01.10.08 10:05:

А не будет ли это нагружать сервер?

О! Ну куда же без этой гениальной фразы.

 

[Духовность™]

*****
Очевидно причина в том, что стандартная распространенная SQL операция со сравнением md5-хэша выглядит примерно так:

select * form table where MD5(CONCAT(user_login, user_mail)) = $hash

т.е. индекс поставить нельзя и теоретически при миллионе пользователей это будет тормозить.

я лично авторизирую пользователя уже ПОСЛЕ того, как вытащил из СУБД все данные пользователя $_COOKIE['id_user']

примерно так:

    /**
    * Метод аутентификации. Принимает md5-хеш из cookie и сверяет его с 
    * md5-хешем логин + пароль.
    * Если сравнение произошло успешно, то $this->id остается как есть.
    * Иначе $this->id принимает значение -1
    * В случае любой ошибки - 0
    */
    public function authentication($user_hash)
    {
        if (!$user_hash || strlen($user_hash) !== 32 || !$this->data || !$this->data['id_user'])
        {
            $this->id = 0;
        }
        
        else if (! (md5($this->data['user_login'].$this->data['user_password']) === $user_hash) )
        {
            $this->id = -1;
        }
    }

 

[флоппик]

теоретически при миллионе пользователей это будет тормозить.

когда у тебя будет миллион практических пользователей, авторизующихся одновременно, то можно будет рассмотреть эту тему.

Очевидно причина в том, что стандартная распространенная SQL операция со сравнением md5-хэша выглядит примерно так:
select * form table where MD5(CONCAT(user_login, user_mail)) = $hash

Очевидно, что имея unique index на логине, который тоже пойдет в условие, это вообще не аргумент.

Да, кстати MD5(CONCAT(user_login, user_mail)) можно превратить в $md5 = md5($login.$email);
и уже потом пихать в sql.

-~{}~ 01.10.08 15:06:

я лично авторизирую пользователя уже ПОСЛЕ того, как вытащил из СУБД все данные пользователя $_COOKIE['id_user']

ты еще не знаешь, пользователь ли это, но уже вытащил его данные?

-~{}~ 01.10.08 15:09:

все данные пользователя $_COOKIE['id_user']

т.е., если я в куку, засуну $_COOKIE['id_user'] = 1;
а потом авторизируюсь с любым валидным аккаунтом, я получу права и данные админа?

-~{}~ 01.10.08 15:10:

* Если сравнение произошло успешно, то $this->id остается как есть.

точно...дайка адресок твоего сайта?

 

[Jackky]

Слишком много разговоров на такую мизерную задачу.

Пожалуй ты прав. Давай, может, пока закрой тему. Когда будут первые результаты (продумаю архитектуру сайта, сформулирую некоторые вопросы и сделаю основной шаблон), то тогда и продолжим дискуссию.
А пока огромное всем спасибо за активное участие в теме. Вы мне очень помогли.

 

[Духовность™]

Да, кстати MD5(CONCAT(user_login, user_mail)) можно превратить в $md5 = md5($login.$email);
и уже потом пихать в sql.

ммм.. ты понял что вообще делает этот код?

т.е., если я в куку, засуну $_COOKIE['id_user'] = 1;
а потом авторизируюсь с любым валидным аккаунтом, я получу права и данные админа?

фик те! ты хоть какой ID засунь, если проверку $_COOKIE['hash'] не пройдет, тебя попросту не авторизует.

вот реальный код: http://phpclub.ru/paste/index.php?show=2168

 

[Gas]

HraKK

Не работает, агу
Там нет алгоритма тупой перебор. для 90% паролей отличных от qwerty не работает.

конечно алгоритма нет, в самом простом случае просто хеш-таблица слов из словаря + самые популярные сочетания. Но, во взял проект на котором зарегистрировано 97K пользователей, среди 50 top-паролей по популярности (в основном простые слова, имена или цифры) результат не был найден только для _одного_, остальными 49 паролями используются 2300 пользователей, что конечно меньше 10%, но если прогнать и остальные, то как знать. Не все ж пользуют пароли в стиле "40 тысяч обезьян в ..." ну вы поняли.

Да, соль к паролям не добавляется, но это упущение и так делать не рекомендую. Зато вот статистику собрал

 

[Фанат]

Я очень глупый вопрос задал, да? Для такого проекта вообще не надо думать о нагрузке на сервер и т.п.?

не проекта, а опыта.
как показывает практика этого форума, новички всегда задумываются по поводу производительности над теми вопросами, которые никакого отношения к ней не имеют. И никогда не задумываются над теми, которые действительно важны.

 

[флоппик]

А еще опыт подсказывает, что далеко не всегда можно правильно угадать узкое место... да и не надо гадать, а надо брать и мерить. По факту. А не предпологать — «а у меня тут может быть, когда нибудь будет узкое место»