Могу ли я предоставить зашифрованную строку пользователям и убедиться, что она безопасна в течение 1-2 часов

Ответ 1

Краткие ответы:

• Из технического POV то, что вы делаете, небезопасно, хотя этого может быть достаточно всего за 2 часа.
• То, что вы пытаетесь сделать здесь, называется "аутентификация сообщения", но это не то, как это должно быть сделано, что, в свою очередь, влияет на безопасность. Вместо этого вы должны использовать HMAC.

Моим советом было бы перейти на CodeIgniter 3 (CI2 перестанет получать даже обновления для системы безопасности через несколько месяцев) как можно скорее и вместо этого использовать новую библиотеку Encryption. Это сделает его безопасным в течение многих лет, а не часов.

Длинный ответ:

Библиотека шифрования должна выполнять как шифрование, так и аутентификацию для вас, но, к сожалению, класс CI_Encrypt плохо написан и не обладает большой функциональностью (например, аутентификацией), поэтому он был DEPRECATED и заменен на новая библиотека (CI_Encryption) в CodeIgniter 3.

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

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

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

С другой стороны, ключи шифрования имеют фиксированную длину (каждый алгоритм шифрования предназначен для работы с определенной длиной ключа, для Rijndael-256 - 32 байта, которые, по-видимому, соответствуют) и не ограничиваются человекочитаемыми символами (что означает большую энтропию и, следовательно, большую безопасность) - они представляют собой сырые двоичные данные.

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

Ответ 2

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

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

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

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

Ответ 3

Вы предоставляете свою логику шифрования/дешифрования на стороне клиента. Хакер легко определит, как совпадают ваши пароли и строки шифрования.

У многих фреймворков есть своя собственная генерация паролей и сравнение логик. Yii с использованием SALT и других функций, таких как SHA1 и т.д.

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

• Создайте пароль шифрования (используя SALT и/или другие инструменты шифрования) и сохраните в конце.
• Попросите клиента (пользователя) ввести свой пароль (ключ) и получить на стороне сервера
• Преобразуйте свой пароль (ключ) в пароль шифрования и сравните

CPasswordHelper будет вам полезен. Попробуйте загрузить исходный код Yii и потушить свою логику для вас.

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

Ответ 4

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

Добавление кода в конец строки называется солярированием строки. Хотя это делает строку сложнее угадать, если вы добавляете твердую кодовую соль вместо случайно генерируемой соли, ее все же можно легко сломать методами грубой силы.

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

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

Также важна информация с любым типом шифрования. Говоря кому-то, что вы добавляете 5 кодонов в свою строку, вы получите некоторое представление о том, как работает ваш алгоритм шифрования. Затем они могут попытаться использовать методы их разбиения на основе информации, которую вы им даете. Попробуйте одно и то же с вашим собственным алгоритмом и оставите учеников в темноте, я сомневаюсь, что кто-нибудь сломает что-нибудь за раз. Многие из методов взлома включают в себя процесс сбора информации, где хакер просматривает или сопоставляет систему, прежде чем пытаться атаковать его.