Какой алгоритм шифрования является лучшим для шифрования cookie?
& можно использовать только для переменных (включая элементы массива или члены структуры) - более формально называемые lvalues . По сути, вы можете использовать его на всем, что может быть на левой стороне = (именно так lvalues получили свое имя). Вы не можете сделать, например, &(1 + 1). Вы также не можете сделать &(&some_variable) по той же причине: &some_variable не является lvalue.
Легко видеть, что это не lvalues, как нельзя было сделать 1 + 1 = something; или &some_variable = something;.
У вас есть &((struct c*)(&((struct a*)0)->y)->j). Или упрощенно, &(&(something)). Это недействительно Я не знаю, что пытается сделать функция, но, возможно, вы использовали две & вместо одной по простой ошибке.
8 ответов
Никакая настоящая причина для не движения с AES с 256 битами. Удостоверьтесь, что использовали это в режим CBC , и дополнение PKCS#7. Поскольку Вы сказали, быстро и безопасный.
я читал (не протестированный), что Шифр может быть незначительно быстрее... Однако Шифр имеет главный недостаток долгого времени установки, которое сделало бы его плохо для Вашей ситуации. Кроме того, AES более "доказан".
Это предполагает, что действительно необходимо симметрично зашифровать Ваши cookie-данные. Как другие отметили, это действительно не должно быть необходимо, и существует только несколько пограничных случаев, где нет никакого другого выбора, но сделать так. Обычно это лучше подошло бы Вам, чтобы изменить дизайн и вернуться или к случайным идентификаторам сессии, или к если необходимые односторонние хэши (использующий SHA-256).
В Вашем случае, помимо "регулярного" случайного идентификатора сессии, Ваша проблема, "помнят меня" функция - это должно также быть реализовано как также:
- долгое случайное число, сохраненное в базе данных и отображенное на учетной записи пользователя;
- или хэширование по ключу (например, HMAC) содержащий, например, имя пользователя, метка времени, mebbe соль И секретный ключ сервера. Это может, конечно, все быть проверенной серверной стороной...
Кажется, что мы добрались немного от темы Вашего исходного, конкретного вопроса - и изменили основание Вашего вопроса путем изменения дизайна....
Так, пока мы делаем, что, я также Настоятельно рекомендовал бы ПРОТИВ , эта функция персистентных "помнит меня", по нескольким причинам, самому большому среди них:
- Делает его намного более вероятно, что кто-то может украсть того пользователя, помнят ключ, позволяя им имитировать идентификационные данные пользователя (и затем вероятно, изменить его пароль);
- CSRF - Перекрестная Подделка Запроса Сайта . Ваша функция эффективно позволит анонимному взломщику заставлять незнающих пользователей отправлять "аутентифицируемые" запросы к Вашему приложению, даже без того, чтобы быть на самом деле зарегистрированным.
AES (также известный как Rijndael) является самым популярным. Размер блока составляет 128 битов, это составляет только 16 байтов, и Вы говорите "приблизительно 100 символов".
Почему Вы хотите зашифровать cookie?
, Поскольку я вижу его, существует два случая: или Вы даете клиенту ключ, или Вы не делаете.
, Если Вы не даете ключ клиенту, тогда почему Вы даете им данные? Если Вы не играете в некоторую странную игру с повреждением слабого шифрования (который Вы явно не), Вы могли бы также хранить данные на сервере.
, Если Вы делаете , вручают клиенту ключ, тогда почему Вы шифруете его во-первых? Если Вы не шифруете коммуникацию ключа, то шифрование cookie спорно: MITM может посмотреть на cookie и отправить Вам любой cookie, который он хочет. Если Вы используете зашифрованный канал для клиента, почему дополнительные издержки шифрования хранивших данных?
, Если Вы волнуетесь по поводу других пользователей на машине клиента, читая cookie, сдайтесь и предположите, что браузер устанавливает хорошие биты полномочий:)
Это затрагивает две отдельных проблемы.
Во-первых, перехват сеанса . Это - то, где третье лицо обнаруживает, скажем, аутентифицируемый cookie и получает доступ к чужим деталям.
, Во-вторых, существует безопасность данных сессии . Этим я подразумеваю, что Вы храните данные в cookie (таком как имя пользователя). Это не хорошая идея. Любые такие данные существенно ненадежны точно так же, как данные HTML-формы ненадежны (независимо от того, какую проверку JavaScript и/или ограничения длины HTML Вы используете, если таковые имеются), потому что клиент свободен отправить то, что они хотят.
Вы будете часто находить людей (справедливо) защищающих санирующий данные HTML-формы, но cookie-данные будут вслепую приняты на номинальной стоимости. Большая ошибка. На самом деле я никогда не храню информации в cookie. Я просматриваю его как сеансовый ключ, и это - все.
, Если Вы намереваетесь хранить данные в cookie, я настоятельно рекомендую Вам пересматривать.
Шифрование этих данных больше не делает информацию trustworth, потому что симметричное шифрование восприимчиво к атаке перебором. Очевидно, AES-256 лучше, чем, скажем, DES (heh), но 256 битов безопасности не обязательно означают столько, сколько Вы думаете, что это делает.
, С одной стороны, СОЛИ обычно сгенерированы согласно алгоритму или в других отношениях восприимчивы к нападению.
Для другого, cookie-данные являются главным кандидатом на хлев нападения. Если это будет известно или будет подозревать, что имя пользователя находится в зашифрованных данных, то будет эй, существует Ваш хлев.
Это возвращает нас первой точке: угон.
нужно указать, что на размещающих общим образом средах в PHP (как один пример) Ваши данные сессии просто хранятся в файловой системе и читаемы кем-либо еще на том же самом хосте, хотя они не обязательно знают, для какого сайта это. Поэтому никогда не храните незашифрованные пароли, номера кредитных карт, обширные персональные данные или что-либо, что можно было бы иначе считать как чувствительное в данных сессии в таких средах без некоторой формы шифрования или, еще лучше, просто храня ключ в сессии и храня фактические уязвимые данные в базе данных.
Примечание: вышеупомянутое не уникально для PHP.
, Но это - серверное шифрование.
Теперь Вы могли утверждать, что шифрование сессии с некоторыми дополнительными данными сделает это более безопасным от угона. Типичным примером является IP-адрес пользователя. Проблемой являются много использования людей тот же ПК/ноутбук во многих различных местоположениях (например, точки доступа Wi-Fi, работа, домой). Также много сред будут использовать множество IP-адресов как исходный адрес, особенно в корпоративных средах.
Вы могли бы также использовать агент пользователя, но это является отгадываемым.
Поэтому действительно, насколько я могу сказать, нет никакой настоящей причины для использования шифрования cookie вообще. Я никогда не думал, что было всего лишь в свете этого вопроса, я пошел смотрящий быть доказанным или право или неправильно. Я нашел несколько потоков о людях, предлагающих способы зашифровать cookie-данные, прозрачно сделать это с модулями Apache, и так далее но они все казались мотивированными путем защиты данных, хранивших в cookie (который, по моему скромному мнению, Вы не должны делать).
я должен все же видеть аргумент безопасности в пользу шифрования cookie, который представляет не что иное как сеансовый ключ.
я буду счастливо доказан неправым, если кто-то может указать на что-то об обратном.
В то время как оба очень сильные, AES является стандартом.
Что касается безопасности маленьких блоков данных: чем меньший - тем лучше. Чем меньше зашифрованных данных представлено, тем дольше можно использовать ключ. Всегда существует теоретический предел того, сколько данных может быть зашифровано в одном ключе данного алгоритма, не подвергая систему риску.
Вы можете безопасно достичь желаемого, используя AES в режиме EAX. Зашифрованный текст будет больше открытого текста; это нормально для безопасного шифрования.
Злоумышленник, конечно, будет знать длину вашего открытого текста из зашифрованного текста, но он не должен быть в состоянии определить что-либо еще.
Генерация ключей AES случайным образом.
Будьте уверены и используйте новый одноразовый номер для каждого шифрования и используйте поле «связанных данных», чтобы гарантировать, что вещь, которую вы зашифровали для одной цели, не отображается как предназначенная для другой (чтобы туда могли входить такие вещи, как имя пользователя и имя файла cookie)
реакции ниже подталкивают к: Do не доверять шифрованию для выполнения безопасность.
Еще: «Если вы не специалист по шифрованию, вы недооцените, насколько легко ошибиться». Например, AFAICT, никто другой в этой цепочке не обсуждал режимы цепочки или целостность сообщения, что покрывает две распространенные ошибки новичков.
Если вы зашифруете файл cookie, серверу все равно придется его декодировать, чтобы прочитать (чтобы проверить тот же ключ), поэтому любой зашифрованный файл cookie бесполезен, потому что в случае кражи (и неотредактировании) он все равно приведет хакера прямо к вашей учетной записи. Это так же небезопасно, как и вообще не зашифровано.
Я считаю, что настоящая проблема кражи ваших файлов cookie - это соединение между сервером и клиентом. Используйте SSL-соединение, предоставленное вашим хостом.
Что касается вашего файла cookie, вам необходимо создать длинный случайный идентификатор для каждого пользователя в базе данных (чтобы он изменялся при каждом входе в систему) и просто установить его как файл cookie или сеанс. Файл cookie, содержащий ключ, можно проверить через php, и если он равен учетной записи или таблице в вашей базе данных, выгрузить данные на веб-страницу, как обычно.
Я думаю, что «отдавая» любые данные, даже зашифрованные, когда это о имя пользователя, и пароль не хороши ... Есть много Js, которые могут понюхать ... Я предлагаю вам создать у пользователей DB Table Tire Pookie_Auth или что-то еще ...
После первого входа Соберите: Ток: браузер, IP, ANS Некоторые собственные ключ Salt, плюс ваше имя хоста VAR ...
Создайте хеш и Хранить в этом поле ... Установите печенье ... Когда cookie "отвечает" Сравните все эти с хранимым хэшем и сделанным ...
Даже если кто-то «украсть» печенье, они не смогут использовать его: -)
Надеюсь, это поможет :-)
Феха Vision.to