ʕ•ᴥ•ʔ Убежище кодИра [Хвали, критикуй, кодь - код]

Как чётко меня расписал.

 

Местные десигнеры даже не догадываются о существовании этого форума (не считая некоторых).

 

Я говорю о тех, кто догадывается. Включая ТС. Видели мы ваши работы, сделанные не по туторам

 

Ну-ка поделииесь?

 

Чем?
http://www.rubukkit.org/threads/Дизайны-которые-ворует-dragoy.61376/

 

Нижуя себе, топтал я в рот эти секреты!

Лишь бы подпись опять все не засрала.

 

Ну как сказать. Те дизайнеры, что называют себя дизайнерами на РБ, не знают что такое дизайн

 

Эххх, ты прав в некотором случае.

 

Жди пару годиков

Ах ты кодЫр наш

 

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

И так, хотел бы подискутировать на тему криптоанализа. (мне на тематический ресурс пока рано идти, слишком мала база знаний)

Причина:

Известно, что доступ в ПУ базы данных на многих хостингам может быть реализован не надежно (например http phpMyAdmin без привязки к IP), и вероятность кражи баз данных велика, да и не хочу полагаться на защищенность окружения.

Посему, хотелось бы обезопасить пароли пользователей хранящиеся в БД, настолько, насколько это возможно в принципе, и узнать по теме максимально много полезной информации.

Следствие:

Пришел к выводу, что для шифрования паролей на данный момент абсолютно безопасно использовать именно blowfish .
Реализовал класс для работы с паролями с применением данного алгоритма BlowfishEncoder

Примитивное обоснование применяемого класса:

Высокая криптостойкость. В основе алгоритма лежит настраиваемая стойкость, с рекомендуемым минимумом от 2^4 раунда (в противовес зачастую применяемым "матрешкам" из 2-х md5 и подобным).

Думаю остановиться на кол-ве раундов в 2^9 - задержка в 0.1 сек на примере Core 2 Duo (эх, почти 8 лет процу уже) - ничтожно маленькая единовременная нагрузка.

Теперь же если вдруг неожиданно кому-то понадобится вскрыть зашифрованный пароль, то для того чтобы сгенерировать небезызвестные таблицы поиска (радужные таблицы) нужно:

1. Учитывать соль, сгенерированную для каждого аккаунта отдельно. Т.е. создавать таблицы поиска придется поаккаунтно (сотни гигабайт таблиц и увеличенное время генерации)
2. Учитывать стойкость хеша. За счет того что алгоритм медленный о генерации радужных таблиц с текущим тех. оснащением не может быть и речи. (хоть единовременная нагрузка и мала, но для генерации миллиарда комбинаций для поакаунтных таблиц перебора это будет настоящим испытанием даже для сети машин)
3. Учитывать особенности реализации конкретного скрипта. В моем случае blowfish применяется для шифрования "матрешки" md5 (за счет чего можно реализовать обратную совместимость с сущ. md5 хешами паролей, приведя их к результирующему) + соли, с возвращением результата в виде md5 хеша результата выполнения шифрования блоуфиша с применением результирующей соли основанной на исходной.

И если не известны особенности (например кол-во раундов хеширования) можно надеяться только на коллизии. Для публичной реализации это конечно не актуально и нужно учитывать, что все данные кроме пароля известны.

Соответственно основная концепция - медленней, значит надежней.
Если у вас есть критика или какие-либо решения (на каком языке без разницы) с учетом максимальной безопасности (чтобы даже мысли о теоретической возможности взлома за приемлемое время не было) при минимальных ресурсозатратах, то не стесняйтесь.

 

Поставлю лайк только потому-что ты потратил много времени на то чтобы это написать.

 

master_crafter, Спасибо за внимание. Когда пишешь подобный разбор полетов, попутно систематизируешь полученные знания. Мне бы не хотелось проводить вышеописанное мероприятие без хотябы какого либо диспута; по этому решил опубликовать свои мысли для начала хотябы здесь.

 

Почему же не подойдет? Все данные - это только то, что видит юзер в базе и не более(только если он не получил доступ к FTP). А если у него есть доступ только к базе, это значит что-то еще можно спрятать и в другое место, например доп. соль в конфиг, которая рандомно генерируется при установке.
Если же это будет так, то вполне подойдет и blowfish. Вот только зачем при таком раскладе делать лишние действия, если подойдет и md5? По моему, целого класса для шифрования, слишком жирно будет. А вот более простой пример из того, что я предлагаю:

PHP:

// $this->cfg['salt'] - random salt after install
// $this->user->salt - user salt from database
$str = $this->cfg['salt'] . $password . $this->user->salt;
$hash = md5(md5($str));

Думаю не стоит говорить о том, сколько лет можно потратить на decrypt такого хэша.

Спойлер: Если же хочется в классе, то вот

PHP:

<?php

class pwd{

    // $pwd - password
    // $u_salt - user salt
    // $c_salt - config salt

    private $u_salt = "XXX"; // salt if extends
    private $c_salt = "XXX"; // salt if extends

    /* Start constructor after new object */
    public function __construct($u_salt, $c_salt){
        $this->u_salt = $u_salt;
        $this->c_salt = $c_salt;
    }

    /* Hash generator */
    public function newPass($password){

        $str = $this->c_salt . $password . $this->u_salt; // create password string

        return md5($this->c_salt.md5($str)); // return result
    }

    /* Password checker */
    public function checkPass($password, $hash){

        $password_hash = $this->newPass($password);

        if($password_hash !== $hash) return false;

        return true;
    }

}

?>


P.s. А вообще я думал, что сейчас придет вот этот неадекват и будет кричать что в webmcr csrf

 

рассматривал такой вариант. Но по мне такой вариант несколько неудобный.
1. Соль нельзя сменить, база будет привязана только к этой соли и в худшем случае придется обнулять или придумывать надстройки, чтобы исключить возможность брута по украденным данным.
2. Конфиг можно потерять, если не информировать о таком нюансе. Это все таки нестандартное решение. И поможет только обнуление базы. Так что только в качестве индивидуального варианта.

По факту это просто неймспейс с нужным функционалом, методы там статичные.

Как ни странно бывает крадут и доступ к ftp (бесплатный хостинг например). Рассмотрим наихудший вариант.

Например известны данные $this->cfg['salt'] и $this->user->salt
Да, таблицы генерировать\использовать не рационально. Но тогда остается шанс для программ вроде этой

680 миллионов паролей в секунду для обычного Md5 (технология CUDA - на видяхе NVIDIA GTX650Ti)

Конкретно твоего примера в сводной таблице не нашел, но если человек разбирается - найдет \ напишет
Некоторые упоминают дикие цифры вроде 15 млрд. хешей в секунду. Я не настолько осведомлен и не могу подтвердить \ опровергнуть в каких случая достигается подобная скорость. Но в идеальных условиях с такими скоростями можно говорить уже о днях взлома, а не о годах.

К тому же если соль будет короткая, процесс будет гораздо быстрее т.к. по факту в твоем примере всего две итерации и скорость генерации хеша будет зависеть в большей степени от длинны соли.

В моем примере же скорость брута замедлена в 1000 раз за счет аналогичного числа итерации. Да и для воспроизведения пароля нужно будет использовать идентичный применяемому мной патерну (стандартную "матрешку" как погляжу реализуют почти в любом бруте), что требует написания индивидуальной программы под CUDA.

 

@NC22, не поймите неправильно, просто хочу хоть что-то понимать. Что есть "соль"?

 

У тя айпод, appl3_w0rm, ах тв свинотка жирная ^_^. Айосер значит, да? Гори в Аду . У меня SIV, никогда не жаловался.

 

KriBetko, Шифруемый пароль в исходном виде зачастую не превышает и 10 символов. Все хеши для подобных паролей легко подбираются, по заранее построенным таблицам хешей. (например c 1 до 7 символов - 64 гига таблиц ) Для защиты и применяют совмещение строки пароля со случайной строкой(собственно соль \ сахар) , генерируя результирующий хеш строки + пароля, таким образом исключая подбор пароля по заранее заготовленным данным.

 

@NC22, вы разработали CMS с ЛК, но не сделали магазин, а почему так? Почему не объединится с @Toster_tpl?
Или я чего-то не знаю?

 

Лул. А че полегче есть?.

А ещё такие скрытые разделы есть у модеров и переводчиков. Ну и не стоит забывать о корзине, которая радовала нас некоторое время