Возможно ли будет взломать пароль с динамической солью которая нигде не хранится?

Question

[StynuBlizz]

Допустим на клиенте вместе с паролем просить пользователя ввести слово (не менее 6 символов, оно и будет солью, которую знает только пользователь, больше она нигде не фигурирует ) и дальше все делать по такой схеме:
hash(password+hash(слово)) и отправлять этот хэш на сервер.
По прибытии данных на сервер делать так: hash(пришедший хэш + соль из БД для этого пользователя) и сверять это с тем что лежит в БД.

Comments

[sim3x]

А когда hash(слово) отправляется?

[StynuBlizz]

Всм

[StynuBlizz]

Оно сначала вместе с паролем хэшируеться а потом отправляеться

[sim3x]

StynuBlizz: как сервер получает соль?

Answer 1

[alex maslakoff]

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

Comments

[StynuBlizz]

Да епт че не понятно то, для того чтобы подобрать пароль нужно подорбрать связку пароль+соль(а она нигде не храниться её знает только пользоваетль) получаеться количетсво вариантов пароля,например: ff=92(количество символов)*92 а количетсво вариантов с неизвестной солью (aa например) будет равно количеству вариантов ff=8464*умножить на количество вариантов aa=8464 т.е равному 71639296

[alex maslakoff]

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

[Денис Загаевский]

StynuBlizz: ничем это не отличается от просто пароля.

Answer 2

[Антон Иванов]

Ваш вариант с солью ничем не отличается от простой авторизации с паролем.
Если у пользователя пароль из 10 символов и соль из двух, то взлом ничем концептуально не будет отличаться от взлома пароля из 12 символов. Будет просто добавлен еще множитель 11 для нахождения позиции разбивки строки из 12 символов на "пароль + соль"

Answer 3

[xmoonlight]

Возможно: ловится хеш (hash(password+hash(слово))) через MiTM и авторизуется кто угодно дальше под этим хешем.
UDP: password+hash(слово) = пароль2, который также подбирается.

Чуть надёжнее, так:
1. На приветствие клиента, сервер генерирует случайную соль и отвечает ею: RSALT
2. Клиент хеширует пароль этой солью, добавив свой случайный параметр RANDOM и свою случайную соль SALT для получения парольного ключа: HKEY=hash(pass+SALT), затем отсылает на сервер 2 параметра:
HASH=hash(RSALT+RANDOM+HKEY), RANDOM
(SALT - также сохраняем на клиенте для последующих авторизаций!)

3. Сервер сохраняет (при установке/смене пароля): HKEY
4. Проверка при авторизации: HASH===hash(RSALT+RANDOM+HKEY)

Таким образом, соль - хранит у нас клиент, а сервер - генерит всегда уникальный запрос.

Comments

[StynuBlizz]

Ну во первых ваши 2 ответа мне помогли,а во вторых они к организовывать соединение (или передавать пароль), а то что я предложил в этом вопросе делает невозможным (?) бутфорс конкретного пользователя при взломе БД. И возникает логичный вопрос какая здесь связь между вашими ответами и этим вопросос?

[StynuBlizz]

они о том как*

[StynuBlizz]

Все идет через https,я не пытаюсь сделать велосипед передающий все безопасно по открытому каналу

[xmoonlight]

StynuBlizz: расписал в ответе..

[Денис Загаевский]

xmoonlight: по-моему, это всё не добавляет секьюрности. При MiTM злоумышленник будет знать все эти ваши параметры, никакой разницы не будет. Нужен нормальный алгоритм, если уж так хочется. Диффи-Хеллман, например. Только сообщения с обоих сторон надо подписывать.

[xmoonlight]

Денис Загаевский: задача была другой. автор хочет избежать утечки пароля из БД. я создал алгоритм. А про Диффи-Хеллман - это уже прошлый век. Есть более лучший обмен ключами.

[xmoonlight]

Денис Загаевский: забыл про MiTM добавить: при авторизации HKEY никогда не передаётся.

Answer 4

[Юрий]

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

ps вы же понимаете что у 99% юзеров: пароль==слово и у большей части к тому же это слова из топ1000 популярных паролей ну максимум даты рождения свои или родственников.

это во первых а во вторых два этих слова браузер не сохранит в хранилище паролей в итоге у ваших юзеров постоянно будут проблемы со входом на сайт.

в третьих очень сложно запомнить и пароль и слово и не перепутать их местами, это еще в вдвойне усугубляет п2.

итого для юзеров создается огромный геморой только из-за того что вы поленились одно поле в базу добавить. а безопасности особо нет.

Comments

[StynuBlizz]

Вы видимо вообще не поняли вопрос?Здесь все так и остается как в стандартной схеме (пароль+соль), только здесь начинает фигурировать еще и соль которую нужно угадать так как она нигде не фигурирует (допустим это 1000 слов). Т.е теперь для подбора пароля методом перебора нужно для каждой буквы подбираемого пароля подгонять еще и 1000 слов соли (а это очень маловероятно что слов будет 1000 т.к это очень мало) следовательно для того чтобы подобрать,например пароль 123456 нужно будет еще и для каждого варианта во время подбора пароля искать нужную соль,а это в разы усложняет задачу. По поводу юзеров: для того чтобы было гемороем запомнить связку (пароль-Pasword123456 и слово(соль)-телевизор например) нужно быть очень недалеким человеком.И да какое поле в данной ситуации я поленился добавить в БД?

[StynuBlizz]

А по поводу проблем со входом на сайт вообще непонятно

[StynuBlizz]

Что бы стало понятей попробуйте представить как вы взламываете пароль сформированный таким методом с помощью брутфорса

[Юрий]

StynuBlizz: "для того чтобы было гемороем запомнить связку (пароль-Pasword123456 и слово(соль)-телевизор например) нужно быть очень недалеким человеком"
это для вас это так, а для меня как пользователя ваш сервис один из примерно сотни, если каждый сервис будет придумывать такие "супер схемы" то я повешусь.

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

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

[Денис Загаевский]

StynuBlizz: твой вариант ничем не отличается от "потребуем пароль длиной не менее M+N символов, первые M символов назовём pass, остальные - salt, дальше действуем по предложенной схеме".

[Юрий]

Денис Загаевский: +1

Answer 5

[jcmvbkbc]

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

hash(пришедший хэш + соль из БД для этого пользователя)

Тут вы говорите о соли в БД, это ок.

hash(password+hash(слово))

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

Возможно ли будет взломать пароль с динамической солью которая нигде не хранится?

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