[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Интересная задача по безопасности
Страницы: 1, 2
sergeiss
Цитата (AllesKlar @ 27.05.2014 - 20:37)
Вряд ли будут покупаться серийки с частотой 5 шт. в секунду. Вот этот сервер ответного ключа и смотрит, что если лимит превышен, то все, вообще, никогда, ничего, никому. До тех пор, пока руками у него флаг блокировки не сбросить.

Заведомо плохой алгоритм. Потому что даже один злоумышленник будет жестко блокировать сервер. Только установишь вручную флаг, как его тут же опять автоматически меняют и нужно опять вручную менять.
"Нормальная паранойя" должна быть smile.gif Но не до такой же степени, чтобы позволять любому блокировать работу сервера.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
FatCat
В качестве ключа шифрования использовать параметр, доступный только на самом сервере. Например мак-адрес сетевого устройства или еще какой-то параметр какой-нидудь железки на сервере.
Соответственно, на другой машине ничего не расшифровать.

_____________
Бесплатному сыру в дырки не заглядывают...
vagrand
FatCat
Если злоумышленник получил доступ на сервер, то что помешает ему узнать макадрес и использовать его для декодирования?

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
vagrand
sergeiss
Идея блокировки частых запросов или как минимум уведомления администратора о подозрительной деятельности на самом деле очень здравая. Вот только это надо делать вдумчиво. Возможно сделать это настраиваемым параметром.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
FatCat
Цитата (vagrand @ 27.05.2014 - 21:56)
Если злоумышленник получил доступ на сервер

То он сгенерирует все серийники штатным методом. От такого уровня взлома шифрованием данных не спастись.

_____________
Бесплатному сыру в дырки не заглядывают...
vagrand
FatCat
Я ведь уже неоднократно в теме писал о том, что серийники не генерется. Это коды пополнения, их предоставляет оператор. Вы что никогда не пополняли мобильник купив пластиковый ваучер с защитной полосой, под которой скрыт пинкод для пополнения?

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
FatCat
Цитата (vagrand @ 27.05.2014 - 22:54)
серийники не генерется

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

_____________
Бесплатному сыру в дырки не заглядывают...
twin
А зачем вообще хранить ключ на сервере? Сгенерировать его и отдать юзеру. СМС-кой допустим для пущей важности. Ну или просто на странице. Мол запомни, без него доступу кирдык. Правда тогда реальный кирдык будет, если он ключ потеряет. Разве что оригиналы хранить в другом месте для аварийных случаев.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
vagrand
FatCat
Ну так в этом и состоял смысл топика, найти возможности или осложнить жизнь злоумышленнику или вообще не дать ему ничего расшифровать.

twin
Цитата
А зачем вообще хранить ключ на сервере? Сгенерировать его и отдать юзеру.


Я уже устал это повторять, всего несколькими постами выше писал почему:
Цитата
Я ведь уже неоднократно в теме писал о том, что серийники не генерется. Это коды пополнения, их предоставляет оператор. Вы что никогда не пополняли мобильник купив пластиковый ваучер с защитной полосой, под которой скрыт пинкод для пополнения?



_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
twin
vagrand
Цитата
Я ведь уже неоднократно в теме писал о том, что серийники не генерется. Это коды пополнения, их предоставляет оператор.
Погоди. Какая разница, генерится он или предоставляется. Вопрос был в том, что нужно уберечся от расшифровки серийника, который в базе. Чем не устраивает моя идея, не пойму. Я же про генерацию ключа, а не серийника написал. Сгенерировать разные ключи, для каждого серийника свой, зашифровать ими серийники и хранить ключи отдельно. На другом сервере допустим, если есть такая возможность. Ну или в другой базе. Юзеру выдавать ключ по двухфакторной идентификации (СМС допустим)... Нет, это не 100% защита, но усложнит довольно прилично.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
sergeiss
Цитата (vagrand @ 27.05.2014 - 22:58)
Идея блокировки частых запросов или как минимум уведомления администратора о подозрительной деятельности на самом деле очень здравая.

Сама идея здравая. Но не вплоть же до того, чтобы потом вручную разрешать! Это уже явный перебор. Я именно это имел ввиду, что всё хорошо в меру.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
vagrand
twin
Цитата
Я же про генерацию ключа, а не серийника написал.


Да, сори, моя ошибка.

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


Да, все, кто отвечал и я в том числе пришли к такому решению. Только мне кажется более надежным хранить на отельном сервере не ключи, а зашифрованные серийники + хранить их разбитыми на части на разных серверах.

sergeiss
Цитата
Сама идея здравая. Но не вплоть же до того, чтобы потом вручную разрешать! Это уже явный перебор. Я именно это имел ввиду, что всё хорошо в меру.


Нет, ну почему же? Главное разработать толковый алгоритм, который будет выявлять опасные ситуации и блочить доступ. Вот только каков этот алгоритм должен быть? Над этим тоже интересно будет подумать.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Игорь_Vasinsky
$key1 = 'secretkey1';
$key2 = 'secretkey2';
$key_code = 'asDFA';

//Твой сенрийник
$code = 'FDa2dfsaf';

//первый кусок 0-4 символа
$path1 = substr($code,0,4);
//второй кусок 5-до конца
$path2 = substr($code,5,20);


$cr_path1 = crypt($path1,$key1); //seN07bBKlhTWc
$cr_path2 = crypt($path2,$key2); //sexjGlbrjI2So

//Длину хешей - хранить в БД - чтобы потом правильно разделить хеши

$len1 = strlen($cr_path1);
$len2 = strlen($cr_path2);

//echo $cr_path1,'<br/>';
//echo $cr_path2;

//склеил и захешировал 2 куска

$cr_code = crypt($cr_path1.$cr_path2,$key_code);

echo $cr_code;//asZdkd6LUB1V6


можно использовать разные виды хешей (так же писать в БД к размерам хешей)

для дешифрования проделать обратный алгоритм (учитывая длину отдельных хешей

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
vagrand
Игорь_Vasinsky
Спасибо конечно, но как шифровать и дешифовать я знаю. Вопрос то ведь был в другом. Где хранить ключи и зашифрованые сирийки так, чтобы даже слив базу их нельзя было расшифровать?

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.