0 Пользователей и 1 Гость просматривают эту тему.
  • 37 Ответов
  • 1983 Просмотров
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
Доброго времени суток!

Не буду пускаться в пространные рассуждения о смысле бытия, дабы не тратить ваше время. Итак.

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

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

В качестве основы этой работы рассматриваю готовое решение новозеландской комании MEGA, разработавшей для своего сервиса онлайн-хранилища довольно интересный алгоритм, он частично есть на GitHub. Приглашаю желающих рассмотреть возможности этого алгоритма, оценить степень его пригодности и обсудить. Если алгоритм окажется надежным и применимым для использования в системах онлайн-коммерции, реализовать его средствами PHP.
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

AlekVolsk

  • Гуру
  • 6915
  • 415 / 4
пару лямов бакинских готов вложить?
*

robert

  • Живу я здесь
  • 4974
  • 457 / 20
Каково решение вопроса монетизации, если продукт написан на PHP?
Не будь паразитом, сделай что-нибудь самостоятельно!
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
пару лямов бакинских готов вложить?
Вот что за люди, а? ))) Нет у меня денег!

Каково решение вопроса монетизации, если продукт написан на PHP?
К примеру, сейчас популярен в России компонент биллинга от joomlaplus.ru. Я видел его изнутри - компонент ни о чем, но за неимением достойных альтернатив люди его покупают, кстати недешево. И довольно часто задают вопросы о том, как натянуть на Жумлу нечто подобное. Сейчас у меня стоит задача создания не то, что бы его аналога, а более развитой системы обслуживания клиентов. Я планирую использовать агрегаторы для совершения платежа, т.к. не потяну свою платежную систему. А хранение данных о текущем виртуальном балансе пользователя должно быть в базе. Разработка алгоритма кодирования данных как раз могла бы помочь решить этот вопрос. А уж как его можно будет монетизировать в других приложениях - голь на выдумки хитра...

Собственно, я не прошу написать за меня код. Я приглашаю подумать и попробовать создать алгоритм работы. Код будет потом... И, если это PHP, естественно он быстро станет достоянием общественности. Поэтому, хоть он и играет ключевую роль, он не главный в плане монетизации.
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

voland

  • Легенда
  • 11030
  • 588 / 112
  • Эта строка съедает место на вашем мониторе
*

dmitry_stas

  • Легенда
  • 13151
  • 1234 / 8
хранилища личных данных не содержат механизмов обеспечения защиты.
что именно вы хотите защитить?
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

capricorn

  • Завсегдатай
  • 1949
  • 118 / 3
вы эту штуку имеете ввиду https://github.com/meganz/webclient
в буржунете критикуют MEGA. http://www.forbes.com/sites/andygreenberg/2013/01/21/researchers-warn-megas-new-encrypted-cloud-cant-keep-its-megasecurity-promises/#4ce352e01f82
2013 год. Что-то изменилось? Я просто спрашиваю, т.к. БМП о чем речь.
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
З а ч е м??
что именно вы хотите защитить?
Я ж написал выше. Данные, хранящиеся в БД.

Я понимаю, что их можно перехватить в момент передачи пакета клиенту, но здесь может применяться js-шифрование, https...

Признаться, я сам не вижу возможностей решения задачи по созданию действительно надежного механизма, но надеялся, что какое то решение может быть...
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

dmitry_stas

  • Легенда
  • 13151
  • 1234 / 8
Я ж написал выше. Данные, хранящиеся в БД.
то, что вы написали, я прочел :) какие именно данные?
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
то, что вы написали, я прочел :) какие именно данные?
Да любые. Переписку с девками в чате, транзакции пользователя, номер телефона проктолога.... Вообщем, буквенно-цифровую. Если я правильно понял вопрос...
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

AlekVolsk

  • Гуру
  • 6915
  • 415 / 4
хороший алгоритм на открытом коде разрабатывать бесполезно, его потребуется защищать (IonCube или аналоги), иначе его быстро хакнут, соответственно хороший алгоритм потребует больших сил и ресурсов, т.е. платить все же придется
а то, что можно пустить в паблик - это уже нельзя назвать хорошим алгоритмом

посмотрите в сторону линейки RC/IDEA, не самые шустрые, но достаточно надежные при грамотном использовании весчи, хоть и устаревшие, зато подзабытые - не сразу кто поймет, шо это и с чем едят, и лучше это действительно делать на js, закрывая https (можно даже заюзать публичный ssl-ключ как один из компонентов защиты, для прозрачного относительно клиента шифрования)
*

fsv

  • Живу я здесь
  • 2765
  • 402 / 2
Недавно думал над этим вопросом. Написал код, ключ на сайте не хранится, вводится юзером.
Забросил, т.к. не смог для себя разогнуть пару запятых:
1) при относительно не большом кол-ве пользователей все нормально, при большом – есть очень не производительный момент с проверкой параметра по всей базе, узкий момент, пока не придумал, как обойти;
2) есть куча мест в админке и на фронте, которые отвалятся, т.к. вся инфа о юзере в базе зашифрована, т.е. нафига оно и где надо?

SeBun, если реально надо и будете дальше думать, в личку почту дайте, скину.
Веб-разработка: заказ. Только новая объемная разработка. Качественно, дорого.
*

AlekVolsk

  • Гуру
  • 6915
  • 415 / 4
а вся шифрованная инфа должна быть только в доп.полях, т.к. это изначально задача не для cms, либо свой двиг поднимать, где шифровать все и сразу
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
SeBun, если реально надо и будете дальше думать, в личку почту дайте, скину.
Мыло в профиле, sebun@ya.ru. Кидайте, посмотрю.
Но опять же, следует иметь ввиду тот момент, что шелл уже залит. Следовательно - декодирование - дело времени. Вот от этого я и хочу попробовать отойти.
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

dmitry_stas

  • Легенда
  • 13151
  • 1234 / 8
Да любые. Переписку с девками в чате, транзакции пользователя, номер телефона проктолога.... Вообщем, буквенно-цифровую. Если я правильно понял вопрос...
а с какой целью это все шифровать?
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
а с какой целью это все шифровать?
Что бы хотя бы максимально усложнить задачу, если уведут базу либо попытаются внести в нее изменения. Я думал, что ответ очевиден...
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

capricorn

  • Завсегдатай
  • 1949
  • 118 / 3
Идея хорошая конечно. Вам плюс за интересную тему. Но как мне показалось у них нет принципиально нового механизма шифрования данных, чтобы на php его реализовывать. Просто как я понял данные шифруются перед отправкой и ключ хранится у пользователя, а не у владельца хранилища данных, как если бы шифрование выполнялось на сервере после получения данных. Извиняюсь, если это мнение нуба. Средствами javascript понятно можно так зашифровать данные перед отправкой. Не понял только насчет php.
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
З а ч е м??

Я вот пять копеек тоже вставлю. Сначала Вы пишете, что нужно защищать:

Цитировать
Данные, хранящиеся в БД.

Затем Вы говорите:

Цитировать
Я понимаю, что их можно перехватить в момент передачи пакета клиенту

Но потом отвечаете на собственные вопросы:

Цитировать
но здесь может применяться js-шифрование, https...

По https (а именно TLS 1.3) я совершенно с Вами согласен. В настоящее время это единственный способ защитить передачу гипертекста от сервера к клиенту. Но JS шифрование -- это как?

Цитировать
Но опять же, следует иметь ввиду тот момент, что шелл уже залит. Следовательно - декодирование - дело времени. Вот от этого я и хочу попробовать отойти.

Вы сейчас про https? Так ключ по-хорошему должен быть доступен на чтение только root-пользователю. Его просто никто открыть не сможет. Можно, конечно, попробовать взломать Апач или Nginx, но удастся ли? Много слов, мало конкретики. Я так же не понял что именно Вы хотите защитить и для чего.

Вы хотите защитить данные, которые передаются от сервера клиенту?
Вы хотите зашифровать базу данных, чтобы при наличии доступа к ней не получилось бы прочесть её данные?

Что конкретно Вы хотите?

Многие приложения используют SSL/TLS и этого, в принципе, достаточно для полноценного шифрования данных. Но структура этих приложений не построена на скриптах -- это бинарники, написанные на C/C++ и прочее, для которых создаётся отдельный процесс. Может, стоит продумать разработку сторонней программы, не являющейся частью PHP? Но опять же, я не могу понять, какие конкретно цели Вы преследуете.
« Последнее редактирование: 19.01.2017, 03:11:22 от Филипп Сорокин »
*

varX

  • Живу я здесь
  • 2450
  • 141 / 5
  • разработка компонентов
Цитировать
устойчивого обратимого шифрования
- тут нужно одно из двух первых слов убрать. Я решал такую задачу при разработке PPF-2. Вообще, это глупая затея для Open source. Но очень сильно затруднить задачу декодирования можно.

Для этого нужно точно знать, какую цель и каким макаром вы преследуете. В любом случае, сам алгоритм под Open source большого значения не имеет. На первом месте - защита ключа шифрования. Если же вас беспокоит только "слив" базы данных, тогда это простая задача, например, обратимо зашифровать пароли к мерчантам можно, и затем хранить шифры в базе. Ключ при этом может быть динамическим и являться функцией от, например, пароля и времени.
Разработка и ремонт. VirtueMart. JoomShopping. Свои компоненты. Принимаю заявки на plasma-web.ru.
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
Многие алгоритмы описаны в учебниках, но это не делает их глупыми и неэффективными. Можно сгенерировать случайный ключ с помощью OpenSSL, поддерживающего более 100 алгоритмов шифрования. Как его хранить и прятать - это уже другой вопрос.
*

capricorn

  • Завсегдатай
  • 1949
  • 118 / 3
ничего уже не понимаю. причем тут https. это шифрование траффика. TLS SSL - это протоколы. SeBun хочет данные шифровать.
« Последнее редактирование: 19.01.2017, 08:41:15 от capricorn »
*

dmitry_stas

  • Легенда
  • 13151
  • 1234 / 8
Я думал, что ответ очевиден...
для меня например не очень очевиден. зачем ломать голову над тем, как зашифровать телефон проктолога - мне например не очень понятно.
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
Но опять же, я не могу понять, какие конкретно цели Вы преследуете.

Хорошо, давайте тогда пойдем по другому пути. Итак, я написал свой сервис обслуживания клиентов, личный кабинет и систему оплаты. Допустим, у меня продаются какие то услуги или электронный товар. Оплата завернута на мерчант. Пользователь имеет свой персональный лицевой счет на сайте, баланс лицевого счета пополняется через мерчант. Сайт использует защищенный протокол (если нет - JS-шифрование трафика, кто в танке - знает). Условимся, что хакер не может вклинится между сервером и клиентом. Первое, что может представлять потенциальную опасность - хранение данных в открытом виде, на которые можно повлиять извне. Допустим, это транзакции, баланс лицевого счета, персональные данные пользователя. Представляем ситуацию - найден иньект. Тут простор для творчества, как его можно применить, но в первую очередь я хочу обезопасить хранящиеся в базе данные, ибо они представляют наивысшую ценность. Следовательно, они должны быть максимально надежно зашифрованы. Но каким образом?

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

Единственная идея, которая мне казалась более рациональной - это одноразовые пароли, высылаемые по SMS на мобильный телефон. Да и то, много ли нужно времени на взлом такой системы?

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

А использовать имеющиеся продукты, а тем более упомянутый мной ранее биллинг - это стрелять себе в ногу. Чего делать совсем уж не хочется.
« Последнее редактирование: 19.01.2017, 17:12:24 от SeBun »
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

voland

  • Легенда
  • 11030
  • 588 / 112
  • Эта строка съедает место на вашем мониторе
Честно - не представляю как это можно, не внедряя третью сторону
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
SeBun, я уже говорил о том, что приложения, применяющие шифрование, запускаются от root пользователя, поэтому имеют доступ к ключам. Другие пользователи к ключам не должны иметь доступа. Так что понять механизм шифрования никто не сможет. Приватный ключ можно защитить парольной фразой, без которой ключ будет бесполезен. Парольную фразу пользователь может вводить в интерактивном режиме.
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
Нашёл вам, кстати, готовый вариант на PHP с использованием приватного ключа и парольной фразы:

Как зашифровать:

Цитировать

$source = "Зашифруй меня!";

$fp=fopen("/path/to/certificate.crt","r");
$pub_key=fread($fp,8192);
fclose($fp);
openssl_get_publickey($pub_key);
openssl_public_encrypt($source,$crypttext,$pub_key);

echo "String crypted: $crypttext";

Как расшифровать:

Цитировать

$passphrase = $_POST['passphrase'];

$fp=fopen("/path/to/private.key","r");
$priv_key=fread($fp,8192);
fclose($fp);
$res = openssl_get_privatekey($priv_key,$passphrase);
openssl_private_decrypt($crypttext,$newsource,$res);

echo "String decrypt : $newsource";

Взято отсюда, дополнено мной.
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
SeBun, гляньте что я для Вас придумал! Мы можем зашифровать данные и без ключей, одним паролем (ключи будут сформированы из него). В качестве алгоритма будем использовать один из самых надёжных на сегодняшний день AES 256 бит в режиме CBC. Немного об этом алгоритме:

Цитировать
Advanced Encryption Standard (AES), также известный как Rijndael (произносится как «Рэндал») — симметричный алгоритм блочного шифрования (размер блока 128 бит, ключ 128/192/256 бит), принятый в качестве стандарта шифрования правительством США по результатам конкурса AES...

В июне 2003 года Агентство национальной безопасности США постановило, что шифр AES является достаточно надёжным, чтобы использовать его для защиты сведений, составляющих государственную тайну (англ. classified information). Вплоть до уровня SECRET было разрешено использовать ключи длиной 128 бит, для уровня TOP SECRET требовались ключи длиной 192 и 256 бит.

Вы всё ещё планируете написать свой алгоритм? Тогда давайте немного пошифруем сначала на BASH, а потом на PHP. Используем чистый openssl:

Код
# Инициализируем переменную парольной фразой
# Из которой будет сформирован ключ для шифрования
PASSWORD="(&7*a$#(*G$&5*$"

# Шифруем строку 'Hello World!'
# Ключ -a переводит бинарный вывод в строку base64
crypt=`printf "Hello World!" | openssl enc -e -aes-256-cbc -a -pass pass:"$PASSWORD"`

# Любуемся результатом
echo "$crypt"

# Расшифровываем при помощи парольной фразы
openssl enc -d -aes-256-cbc -a -pass pass:"$PASSWORD" <<< "$crypt"

Теперь выполним похожие действия на PHP. Хотя используется один и тот же алгоритм, эти подходы не являются идентичными, есть кое-какие отличия -- о них ниже:

Код
// Парольная фраза
$password = "(&7*a$#(*G$&5*$";

// Вектор инициализации, делающий шифр неповторимым
// В openssl формируется из парольной фразы, если не задан принудительно
// В PHP мы должны сначала его получить
// Пусть это будет 16 символов md5 хеша пароля
// Размер строки для этого вида шифрования составляет 16 байт
$iv = substr(md5($password, true), 0, 16);

// Шифруем и переводим результат в base64 (значение 0 в 4-ом параметре)
$crypt = openssl_encrypt("Hello World!", "aes-256-cbc", $password, 0, $iv);

echo $crypt;

// Расшифровываем. Но перед этим по такому же механизму
// получаем вектор инициализации. Если вектор будет отличаться,
// то расшифровать данные не получится
echo openssl_decrypt($crypt, "aes-256-cbc", $password, 0, $iv);

Не благодарите :)
« Последнее редактирование: 22.01.2017, 20:20:27 от Филипп Сорокин »
*

SeBun

  • BanMaster
  • 4018
  • 259 / 5
  • @SeBun48
Вы всё ещё планируете написать свой алгоритм?

Филипп, все равно скажу спасибо хотя бы за проявленный интерес. Я знаком с AES и другими методами шифрования, есть так же собственный алгоритм, переделанный из китайского с упаковщиком текста (то есть не просто шифруется, но и сжимается), а пароль содержит в себе так же и номер ячейки (ID), в которой хранится запись, причем алгоритмов создания пароля несколько. Но суть не в том. Мы зашифровали, но для того, что бы расшифровать данные, скрипт должен применить ключ. Допустим, происходит транзакция пополнения кошелька. Выполняется шифрование данных, данные помещаются в БД. Где то должен лежать ключ либо список ID=KEY, что бы его можно было быстро достать и декодировать данные, если, к примеру, клиент смотрит историю платежей. Тогда возникает та самая дилема, и даже две - где хранить ключи и как обезопасить скрипт, выдающий ключи, и как, в конце концов, не дать подделать выдачу ключа? Я ведь не буду требовать от каждого пользователя вставлять свой e-Token в технологическое отверстие...

В данном варианте мы имеем плюс в том, что данные зашифрованы хорошо (не надежно, а хорошо, ибо нет у меня доверия к АНБ и их выводам). Но вопрос в хранении ключа сводит это шифрование на нет.

Если попробовать представить, что часть пароля хранится у пользователя. К примеру, в базе у него хранится некая соль, пароль запрашивается один раз при входе в личный кабинет и хранится, к примеру, на сервере в переменной сессии. Декодер, который может храниться вместе со списком ID=KEY где то за пределами корня, получает в качестве пароля хеш соль+пароль, и отдает расшифрованные данные или выполняет транзакции. Но! Как увести сессию - мы все прекрасно знаем. Так же, если учесть, что шелл дает возможность смотреть в том числе и переменные сессии, нетрудно этот самый пароль получить, просто внедрив в код пару лишних строк. Здесь остается надеяться лишь на быстрое обнаружение измененного/добавленного файла, а это круглосуточный мониторинг и зарплата админу...

Что то мне подсказывает, что иного решения просто не будет...
Оказываю услуги по Joomla | Миграция/Обновление | Сопровождение | IT-аутсорсинг | Недорогие домены и хостинг
*

Филипп Сорокин

  • Завсегдатай
  • 1918
  • 160 / 4
  • разработчик.москва
Изначально у вас была задача защититься от слива базы, что можно сделать вполне стандартными средствами. Конечно, можно прочитать ключ отдельного юзера в момент его авторизации, но другие пользователи останутся защищёнными. Шелл - это шелл. Против водородной бомбы нет абсолютной защиты. Что же касается транзакций, то это другая тема. Транзакции не требуют длительного хранения ключей - вполне пригодны и одноразовые. Механизм реализации будет зависеть от конкретных задач. Как я говорил ранее, можно вообще 2 параллельных сервиса запилить, которые не будут пересекаться друг с другом.
*

dmitry_stas

  • Легенда
  • 13151
  • 1234 / 8
Что то мне подсказывает, что иного решения просто не будет...
что то вы подозрительно быстро пришли к правильному выводу, как для человека который озадачился данной проблемой :) вероятно, уже давно обдумываете это.

SeBun, вам Филипп озвучивает абсолютно здравую мысль. вы пытаетесь решить нерешаемую задачу. оставьте безопасность пользователя для пользователя. займитесь своей. нет никакой разницы зашифрованы данные юзера или нет, если злоумышленник выдал себя за легального юзера, а вы ему поверили. поэтому в данной ситуации ваша задача не ломать голову, как защитить юзера от кражи пароля иди перехвата сессии. вы этого все равно не сможете сделать. ваша задача - максимально усложнить для злоумышленника кражу сессии или вход под логином/паролем юзера. привязка к IP, авторизация в несколько этапов, и т.п - это то, что вам нужно. а думать за юзера, что бы такого сделать, чтоб его пароль никто не узнал - вам не нужно.
Тут дарят бакс просто за регистрацию! Успей получить!
Все советы на форуме раздаю бесплатно, то есть даром. Индивидуально бесплатно консультирую только по вопросам стоимости индивидуальных консультаций
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться