Можно ли отменить шай?

Ответ 1

Нет, вы не можете отменить SHA-1, именно поэтому он называется алгоритмом безопасного хэша.

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

И вы, вероятно, должны использовать SHA-256 для новых систем.

sha("My Secret Key"+"a timestamp" + the whole message to be signed)

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

Если атака грубой силы возможна, зависит от длины вашего секретного ключа.

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

Ответ 2

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

Однако SHA-1 имеет некоторые недавно обнаруженные недостатки, которые позволяют находить ввод быстрее, чем путем поиска грубой силы всех входных данных. Вы должны рассмотреть возможность использования чего-то более сильного, например SHA-256 для новых приложений.

Jon Callas на SHA-1:

Пришло время ходить, но не бегать, к огненным выходам. Вы не видите дыма, но пожарные тревоги ушли.

Ответ 3

Вопрос на самом деле, как пройти проверку подлинности через небезопасный сеанс.

Стандарт, почему это нужно, - использовать дайджест сообщения, например. HMAC.

Вы отправляете текстовый текст сообщения, а также сопровождающий хэш этого сообщения, в котором был помещен ваш секрет.

Итак, вместо вашего:

sha1("My Secret Key"+"a timestamp")

У вас есть:

msg,hmac("My Secret Key",sha(msg+msg_sequence_id))

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

Это отраслевой стандарт и безопасный способ аутентификации сообщений, независимо от того, зашифрованы они или нет.

(вот почему вы не можете перетаскивать хэш:)

Хеш - это односторонняя функция, означающая, что многие входы производят одинаковый вывод.

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

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

Таким образом, принципиально нет возможности сбрасывать хэш с какой-либо определенностью.

Ответ 4

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

Итак, нет, хеш-функции не могут быть отменены. Но вы можете искать такие столкновения.

Edit

Как вы хотите аутентифицировать связь между вашими системами, я бы предложил использовать HMAC. Эта конструкция для вычисления кодов аутентификации сообщения может использовать разные хэш-функции. Вы можете использовать SHA-1, SHA-256 или любую желаемую функцию хэша.

И чтобы аутентифицировать ответ на конкретный запрос, я отправил nonce вместе с запросом, который должен использоваться как соль для аутентификации ответа.

Ответ 5

Обратите внимание, что лучшие атаки против MD5 и SHA-1 заключались в поиске любых двух произвольных сообщений m1 и m2, где h (m1) = h (m2) или нахождения m2 таких, что h (m1) = h (m2) и m1!= m2. Нахождение m1, заданное h (m1), по-прежнему является вычислительно неосуществимым.

Кроме того, вы используете MAC-код (код аутентификации сообщения), поэтому злоумышленник не может забыть сообщение, не зная тайны с одним предостережением - общая конструкция MAC, которую вы использовали, подвержена атаке расширения длины - злоумышленник может некоторые обстоятельства создают сообщение m2 | m3, h (секрет, m2 | m3), заданное m2, h (секрет, m2). Это не проблема только с меткой времени, но это проблема, когда вы вычисляете MAC над сообщениями произвольной длины. Вы можете добавить секрет к timestamp вместо предварительного ожидания, но в целом вам лучше использовать HMAC с дайджером SHA1 (HMAC - это просто конструкция и может использовать MD5 или SHA в качестве алгоритмов дайджестов).

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

Лучше всего отправить сообщение, HMAC (сообщение) с достаточно длинным секретом. Сервер может быть уверен в целостности сообщения и подлинности клиента.

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

Ответ 6

Не совсем верно, что вы не можете отменить зашифрованную строку SHA-1.

Вы не можете напрямую изменить один, но это можно сделать с помощью таблиц радуги.

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

По сути, SHA-1 безопасен только в качестве используемого пароля. Если у пользователей есть длинные пароли с неясными комбинациями символов, очень маловероятно, что существующие таблицы радуги будут иметь ключ для зашифрованной строки.

Вы можете проверить свои зашифрованные строки SHA-1 здесь: http://sha1.gromweb.com/

В Интернете есть другие радужные таблицы, которые вы можете использовать для Google reverse SHA1.

Ответ 7

Хеши зависят от входа, и для того же входа выдаст тот же результат.

Итак, в дополнение к другим ответам, пожалуйста, помните следующее:

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

Итак, вместо использования sha1 ( "Мой секретный ключ" + "временная метка" )

пойти на sha1 ( "метка времени" + "Мой секретный ключ" )

Ответ 8

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

Потому что, хотя технически очень сложно переборщить или изменить хеш SHA, когда вы отправляете текстовые "данные и хэш данных + секрет" через Интернет, как отмечалось выше, можно разумно получить секрет после захвата достаточного количества образцов ваших данных. Подумайте об этом - ваши данные могут меняться, но секретный ключ остается неизменным. Поэтому каждый раз, когда вы отправляете новый блок данных, это новый образец для запуска основных алгоритмов взлома. С двумя или более образцами, которые содержат разные данные и хэш секретности данных +, вы можете проверить, что секрет, который вы определяете, является правильным, а не ложным.

Этот сценарий похож на то, как взломщики Wifi могут взломать пароли wifi после того, как они захватят достаточно пакетов данных. После того как вы соберете достаточно данных, тривиально создать секретный ключ, даже если вы технически не изменяете SHA1 или даже SHA256. Единственный способ убедиться, что ваши данные не были подделаны или для проверки того, с кем вы разговариваете на другом конце, заключается в шифровании всего блога данных с использованием GPG или тому подобного (общедоступные и закрытые ключи). Хеширование по своей природе ВСЕГДА небезопасно, когда данные, которые вы хешируете, видны.

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

Примечание. Это был один из способов, которым англичане смогли взломать код Enigma во время Второй мировой войны, что привело к одобрению союзников.

Любые мысли об этом?

Ответ 9

SHA1 был разработан для предотвращения восстановления исходного текста из хеша. Тем не менее, существуют базы данных SHA1, которые позволяют искать общие пароли по их SHA-хешу.