2017-02-01 13 views
0

Мне нужно сделать хэш SHA1, единственный вариант - использовать Javascript (из-за моего клиента, использующего сторонний продукт) SHA1 требуется передать некоторую информацию на платежный шлюз. поэтому следующая информация должна быть передана SHA1 для преобразования в хэш (имя пользователя, пароль, сумма), а затем передана на платежный шлюзМожно ли использовать javascript sha1?

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

благодаря

+3

этого недостаточно информации для продолжения. – Alnitak

+0

Обновлен вопрос – user2206329

+0

Итак, сторонний продукт хранит пароли в виде обычного текста? – fafl

ответ

0

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

Если вы используете хеширование на стороне сервера, исходный текст не отображается в браузере. Крайне сложно «перевернуть» хэш SHA-1, но не «невозможно» - с достаточной силой грубой силы, вы могли бы хотя бы найти хеш-столкновение (другая строка, которая производит тот же хеш).

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

Если речь идет о паролях, вы должны изучить BCrypt.

0

Нет, не делайте этого!

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

Краткий обзор хэширование паролей:

Каждый пользователь имеет пароль, что ваш сервис знает. Они используют его для входа в систему. Представьте, что вы сохранили их в простой текст. Это было бы плохо, если бы кто-то копировал вашу базу данных. Таким образом, вы получаете каждый пароль с помощью алгоритма md5 или sha1. Хеш нельзя использовать для воссоздания пароля, но вы можете проверить пароль, если он действителен. Задача решена?

Не совсем. Для алгоритма хэширования просто создать таблицу радуги . Таким образом, вы можете быстро найти возможные входные значения для каждого хэша. Итак, вы соль. Это означает, что каждый пользователь имеет случайную строку, которая добавляется к паролю перед хэшированием, создавая уникальную функцию хэширования для каждого пользователя. Отличное решение?

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

+0

Несколько проблем с этим: 1. Нельзя сказать, что (хэшированный) пароль неправильно хэширован и солен/снова/на стороне сервера. Вы этого не знаете, так что это всего лишь предположение. 2. Пользователь нигде не упоминает, что хэш используется для аутентификации. Опять же это предположение. Вопрос состоял в том, что «люди не могут просто просматривать источник и видеть вещи, которые я хеширую» - вопрос не задавал вопрос о безопасности сервера или аутентификации. –

+0

Да, я мог бы ответить на другой вопрос :) – fafl