SubbZer Ответов: 2

Данные пароля (хэш? ) Всегда пригоден для использования

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

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

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

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

Как такое может быть? Я думал, что срок действия ключа истечет?
Мы должны предоставить владельцу продукта подробную информацию, прежде чем он что-либо предпримет..

Спасибо за помощь и извините за не самый лучший английский

Что я уже пробовал:

Я попробовал google "javascript password encoding", чтобы понять основные вещи...

2 Ответов

Рейтинг:
2

F-ES Sitecore

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

SubbZer

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

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

F-ES Sitecore

Не зная точно, как работает система, трудно сказать, почему что-то происходит или как все можно изменить.

SubbZer

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

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

Рейтинг:
0

Richard Deeming

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

Безопасная Аутентификация Паролем Объясняется Просто[^]
Соленое хэширование паролей - делаем это правильно[^]


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

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


Вы упомянули о копировании и повторной отправке запроса, что говорит о том, что вы беспокоитесь о том, что злоумышленники перехватывают трафик на ваш сервис. Для этого есть простое решение: HTTPS / TLS. Все запросы к вашему сервису будут автоматически зашифрованы таким образом, что только ваш сервер сможет их прочитать. Все ответы от вашего сервиса будут автоматически зашифрованы, так что только пользователь, сделавший запрос, сможет их прочитать.

HTTPS - Википедия[^]