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

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

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

Предположим, что я создаю sha1, подобный этому, с помощью ввода «секретного ключа» и придаст ему временную метку, чтобы sha все время менялся.

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

Затем я включаю этот sha1 в сообщение и сервер, которые могут выполнять одни и те же вычисления. И, надеюсь, никто не сможет понять «секретный ключ».

Но действительно ли это так?

Если вы знаете, что так я это сделал, вы бы знали, что я поставил там временную метку, и вы увидите sha1. Можете ли вы затем использовать эти два и выяснить секретный ключ?

 secret_key = bruteforce_sha1(sha1, timestamp) 

Благодаря Johan


Примечание1 : Я предполагаю, что вы могли бы использовать грубую силу каким-то образом, но насколько это будет на самом деле?

Note2 : Я не планирую шифровать какие-либо данные, я просто хотел бы узнать, кто их отправил.

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

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

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

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

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

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

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

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

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

Джон Каллас на SHA-1:

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

На самом деле вопрос заключается в том, как пройти аутентификацию по небезопасной сессии.

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

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

Поэтому вместо вашего:

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

У тебя есть:

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

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

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


(вот почему вы не можете скопировать hash 🙂

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

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

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

Таким образом, в принципе, нет никакого способа отменить hash с какой-либо определенностью.

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

Таким образом, нет, hash-функции не могут быть отменены. Но вы можете искать такие столкновения.


редактировать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, вместо использования sha1 («My Secret Key» + «timestamp»)

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

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

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

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

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

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

Любые мысли по этому поводу?

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

  • WSS по HTTP и WSS на HTTPS
  • Какова наилучшая практика для работы с паролями в репозиториях git?
  • Отключить политику одинакового происхождения Firefox.
  • Защита паролем в файле свойств
  • Как получить местоположение cacerts стандартной java-установки?
  • Как проверить, существует ли class в пакете?
  • Как безопасно сохранять имя пользователя / пароль (локально)?
  • Параметры querystring безопасны в HTTPS (HTTP + SSL)?
  • Как сервер станет уязвимым с помощью chmod 777?
  • Защита CSRF: нужно ли нам генерировать токен для каждой формы?
  • Как проверить загруженный файл в ASP.NET MVC?
  • Давайте будем гением компьютера.