Это ерунда, а не аналог второго пароля.
«второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.
Это хождение по кругу.
Просто вместо password становится Hs(password, salt).
Если для входа на сервер нам надо знать не пароль, а хэш — то хэш теперь становится тем «паролем», зная который, можно войти на сервер. И в итоге этот «пароль» хранится на сервере в открытом виде.
про «введённое пользователем» — это тоже лишнее, и ведёт к инъекциям.
Так что просто «никогда не подставлять в запросы непосредственно ничего». Точка.
А только через плейсхолдер или белый список.
И плюс ещё про Digest авторизацию (которая challenge-response) — она, увы, несовместима с хэшированием паролей. Поэтому — только SSL. Тем более, что это совсем несложно.
Существует несколько общепринятых объяснений.
Одно из них — болшинство хомячков имеет один и тот же пароль подо все сервисы => можно уводить мыло, твиттер и пр.
Или, авторизовавшись можно получить доступ на запись, а слив мог быть произведён только через чтение — и пр.
Эм. Что мы имеем в виду под «всеми» компонентами?
Грубо, закрытый ключ — это аналог пароля. Если он известен атакующему, то все остальное становится ненужным. Мы говорим о взломе или о чём?
Если не устраивает ответ, то тогда стоит конкретизировать вопрос.
К сожалению, вы не поняли обсуждаемого вопроса.
Точно так же я могу задать встречный вопрос — «Есть хэши, но соль неизвестна. Предлагаю размяться».
Или — «есть база, пароли лежат в открытом виде». Узнайте пароли.
При анализе уязвимости надо всегда предполагать худший сценарий. Тот факт, что я не откадаю пароль в вашей задачке, никак не поможет человеку, у которого скомпрометированным окажется «секретный» параметр.
А игры «отгадай число, которое я задмуал» стоит оставить для детского сада.
Ну, строго говоря, при использовании современных функций хэширования, отдельное поле действительно не нужно — соль генерируется вместе с хэшем, и функция возвращает (и принимает) их единой строкой.
Можно разрешать простые пароли.
Только надо понимать, что никакие алгоритмы с «локальными параметрами» такой пароль не защитят.
И в очередной раз закипая яростью благородной по поводу ламеров, не умеющих солить — о таком важном в звене защиты упоминать надо обязательно. Оговаривая, что при простом пароле все вышеперечисленные методы окажутся неэффективными.
Криптография не строится на допущениях. Рассуждения вида «что требуется взломать, чтобы добраться туда-то» относятся к безопасности приложения в целом. Но если говорить о безопасности конкретно хэшей, то только стойкий пароль (в сочетании с остальными правилами) может действительно её гарантировать.
Рассуждения типа «а вот мы придумаем тайное слово и никому его не скажем» — это детская игра в секретики.
Он добавляется к паролю при хэшировании — то есть, используется, как соль :)
Где она хранится — вопрос десятый. Хранение вместе с хэшем — это просто частный случай.
Предполагать, что «секретная соль» неизвестна атакающему — это ровно то же самое, что предполагать, будто у атакующего нет доступа к хэшам.
Простите, но у вас каша в голове :)
Начиная с того, что для алгоритма хэшированя скорость не достоинство, а недостаток — скорость однократного создания хэша при авторизации не критична, а вот при переборе чем медленнее алгоритм, тем сложнее брутфорс.
И, разумеется, никто не шифрует пароли совсем не потому что это «медленнее».
Автор уповает. Я там ниже вам написал, что вы изобрели себе какой-то «локальный параметр» и по какой-то неведомой причине полагаете, что он чем-то принципиально отличается от соли. Это даже забавно. Такой метод ведения дискуссии — изобрести ничего не значащее слово и ссылаться на него :)
«второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.
Просто вместо password становится Hs(password, salt).
Если для входа на сервер нам надо знать не пароль, а хэш — то хэш теперь становится тем «паролем», зная который, можно войти на сервер. И в итоге этот «пароль» хранится на сервере в открытом виде.
Так что просто «никогда не подставлять в запросы непосредственно ничего». Точка.
А только через плейсхолдер или белый список.
И плюс ещё про Digest авторизацию (которая challenge-response) — она, увы, несовместима с хэшированием паролей. Поэтому — только SSL. Тем более, что это совсем несложно.
поэтому, чтобы не выбирать из двух зол — только шифрование канала.
Одно из них — болшинство хомячков имеет один и тот же пароль подо все сервисы => можно уводить мыло, твиттер и пр.
Или, авторизовавшись можно получить доступ на запись, а слив мог быть произведён только через чтение — и пр.
Грубо, закрытый ключ — это аналог пароля. Если он известен атакующему, то все остальное становится ненужным. Мы говорим о взломе или о чём?
Если не устраивает ответ, то тогда стоит конкретизировать вопрос.
Точно так же я могу задать встречный вопрос — «Есть хэши, но соль неизвестна. Предлагаю размяться».
Или — «есть база, пароли лежат в открытом виде». Узнайте пароли.
При анализе уязвимости надо всегда предполагать худший сценарий. Тот факт, что я не откадаю пароль в вашей задачке, никак не поможет человеку, у которого скомпрометированным окажется «секретный» параметр.
А игры «отгадай число, которое я задмуал» стоит оставить для детского сада.
— В контексте моей модели задача решена не для скачек вообще, а для случая сферического коня в вакууме.
=)
Другая история про перебор по словарю — это очень, очень смешно.
Как алгоритмы, так и «соль» — открытый ключ — заведомо известны и даже по возможности широко распространяются.
Только надо понимать, что никакие алгоритмы с «локальными параметрами» такой пароль не защитят.
И в очередной раз закипая яростью благородной по поводу ламеров, не умеющих солить — о таком важном в звене защиты упоминать надо обязательно. Оговаривая, что при простом пароле все вышеперечисленные методы окажутся неэффективными.
Рассуждения типа «а вот мы придумаем тайное слово и никому его не скажем» — это детская игра в секретики.
Где она хранится — вопрос десятый. Хранение вместе с хэшем — это просто частный случай.
Предполагать, что «секретная соль» неизвестна атакающему — это ровно то же самое, что предполагать, будто у атакующего нет доступа к хэшам.
И это. Нет никакой «глобальной», «локальной» или «специальной» соли. Есть просто соль. Она заведомо известна атакующему. Это азы.
Начиная с того, что для алгоритма хэшированя скорость не достоинство, а недостаток — скорость однократного создания хэша при авторизации не критична, а вот при переборе чем медленнее алгоритм, тем сложнее брутфорс.
И, разумеется, никто не шифрует пароли совсем не потому что это «медленнее».
Автор уповает. Я там ниже вам написал, что вы изобрели себе какой-то «локальный параметр» и по какой-то неведомой причине полагаете, что он чем-то принципиально отличается от соли. Это даже забавно. Такой метод ведения дискуссии — изобрести ничего не значащее слово и ссылаться на него :)