Создаю систему, где есть юзеры без регистрации (хранения данных). После подключения к серверу клиент отправляет пару полей - логин и пароль. Далее эти данные смешиваются (добавление поля в json) с секретной фразой и хэш отправляется пользователю обратно. Пользователь шарит данный идентификатор в качестве своего опознавательного ключа для других юзеров, которые могут с ним взаимодействовать (т.е. отправляет этот ключ в публичный доступ).
Какие подводные могут быть? Хэши вроде необратимые, а брутфорс и радужные таблицы бесполезны при использовании соли (т.е. моего заданного секрета в поле).
Проблема в соли.
Если соль разная для каждого пользователя, то её нужно хранить на сервере, а это противоречит исходным условиям.
Если соль одинаковая для всех, то нет смысла в соли - ломается примерно так же, как и без соли.
Не могу припомнить никакую криптографию, в которой бы соль делали секретом (хотя само по себе это не является проблемой).
Не могли бы объяснить, почему здесь соль боттелнек ?
Я в криптографии не силен, по моим сведениям даже статическая соль поможет от перебора.
Если это действительно имеет крупные основания, поможет ли генерить соль на основании логина и пароля, например с помощью KDF?
Israfil22, идея соли в том, что она генерируется случайно для каждого пользователя и хранится в открытом виде.
Допустим, что соль одна на всех и является секретом. Тогда злоумышленник выворачивает наизнанку любой популярный метод взлома, логин и пароль он может задавать сам, а ломать он будет вместо пароля вашу общую соль.
На основании логина и пароля генерировать соль тоже нет смысла. Это будет не соль, а лишь изменение криптографического алгоритма.
...логин и пароль он может задавать сам, а ломать он будет вместо пароля вашу общую соль.
Можно подробнее? Насколько мне понимается, это невозможно.
Достаточно поставить задержку в секунду на сервере, чтобы метод перебора перестал быть возможным.
Если же соль генерируется динамически для каждого прообраза индивидуально, используя некоторые уникальные параметры для каждого пользователя, то стойкость системы повышается. wiki
Достаточно поставить задержку в секунду на сервере, чтобы метод перебора перестал быть возможным.
Если алгоритм не является секретом (а это один из важных принципов криптографии), то злоумышленник может запустить этот же алгоритм на своём сервере без задержки.
Ну мне не очень удаётся сформулировать мысль так, чтобы было понятно. :) Может быть кто-то ещё ответит или прокомментирует с другой точки зрения, с другими аргументами. Подпишусь, послежу за ответами.
hint000, так, это понял. Локально можно запустить тот же инстанс хэша.
А если его не сообщать + использовать KDF, то выходит, что это пусть в один конец.
Dmitry Bay, я думаю в этом нет никакой существенной проблемы. Архитектурно: да, можно не использовать пароль, но зачем?
Привычная связка, сложностей дополнительных не накладывает, скорее даже наоборот. Меньше теоретических коллизий с другими юзерами, не нужно заново изобретать себе секретную фразу для одного приложения.
не нужно заново изобретать себе секретную фразу для одного приложения.
IMHO любой, кто заботится о ИБ, не будет использовать один и тот же пароль на двух независимых сайтах или в двух независимых приложениях. Разумеется, для каждого сайта и приложения придумывается новый пароль, а как иначе. Исключения составляют сайты, на которых регистрируешься, чтобы скачать один файл или написать один комментарий, и больше не собираешься туда заходить - там можно и пароль Qwertyuiop задавать.
hint000, это - выбор пользователя) Заставлять жить так, как видится мне - неэтично хотя бы. Моя зона ответственности, как разработчика, предоставить удобство взаимодействия и возможность безопасного использования решения. А вот потенциальный юзер должен сам решить, как ему распоряжаться своими данными.
Простой
