Отправка зашифрованного текста и последующая расшифровка на сервере - что такое надежная встроенная функция PHP? - PullRequest
0 голосов
/ 16 ноября 2011

Хорошо, у меня было много идей (также много на SO) ... но я думаю, что нашел мейкера.

  1. У меня есть конфиденциальная информация, которую пользователи вводят в форму.
  2. После отправки этой формы информация будет зашифрована с ключом (уникальным для этого пользователя, известным только этому пользователю), и этот зашифрованный текст будет отправлен по электронной почте на электронную почту пользователя. Текст (не зашифрованный) обычно <20 символов. </li>
  3. После этого пользователь сможет войти на сайт, используя уникальный для него пароль. Затем они могут ввести зашифрованную строку вместе со своим уникальным ключом и просмотреть незашифрованную информацию (я могу расшифровать ее с помощью ключа, который они предоставляют - ключ хранится в БД, как и пароль, - он хэшируется, и хеш сравнивается при вводе пользователя).

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

Если этот рабочий процесс звучит нормально - какие функции и опции PHP могут предложить люди для надежного шифрования? Какие-нибудь сэмплы где-то там плавают?

Спасибо!

Ответы [ 2 ]

1 голос
/ 16 ноября 2011

Что произойдет, если пользователь потеряет ключ?

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

Если эта опция не работает для вас, потому что вам нужно ее прочитать, создайте вторую систему, которая подключена только к веб-серверам (а не к Интернету). Эта система требует строгой аутентификации от каждого веб-сервера и рассматривает каждый веб-сервер как ненадежный источник. Таким образом, вы обеспечите безопасность политикой. Веб-серверу не будет разрешено извлекать больше X записей пользователя в минуту (таким образом, защищая всю базу данных от взлома). Кроме того, вы можете обеспечить тщательный мониторинг и отчетность, и вам нужно будет часто поворачивать ключи авторизации для веб-сервера.

Не зная, в чем собственно проблема домена, нам трудно порекомендовать, оправдан ли какой-либо из этих методов. Я просто пытаюсь предоставить вам варианты, если вы считаете, что они оправданы.

Однако самая распространенная дыра в безопасности - это люди. У кого есть доступ к серверу? Какой уровень кодирования находится на сервере приложений? Проводятся ли регулярные аудиты безопасности в вашей системе надежной консалтинговой компанией, которая имеет опыт аудита исходного кода на вашем языке или в вашей среде?

Надеюсь, это поможет

UPDATE:

В отношении хеширования:

См: http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

http://www.md5decrypter.co.uk/sha1-decrypt.aspx

Хеширование должно быть сделано с осторожностью

0 голосов
/ 16 ноября 2011

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

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

Также в этот момент стоит спросить - есть ли у них ключ и есть ли зашифрованный текст, зачем им нужно, чтобы вы расшифровывали его?Обычно шифрование - это не то, что вы хотите делать самостоятельно (то есть использовать установленные алгоритмы / схемы шифрования).Поскольку они установлены / открыты, пользователи смогут расшифровывать без вас.Если это просто вопрос удобства, то это может быть уже потеряно, если вы потребуете, чтобы пользователи запоминали ключ для каждого фрагмента данных, а также должны сами хранить и управлять зашифрованным текстом.


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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...