Достаточно ли сильной будет такая схема хэширования с двойной солью?

Question

[StynuBlizz]

Приложения на андройд:
Пользователь логиниться и на сервер отправляеться такие данные пароля
(hash (hash password)+(что-то взятое из хэша пароля в качестве соли))

На сервере:
Получая это хэш и делаю следущее:
(hash((hash(хэш пришедший в запросе))+(hash(соли которая лежит в бд)))
Ну и сверяю то что получилось с тем что лежит в бд

В результате получается соль которая нигде не храниться и для того чтобы взломать пароль нужно будет узнать алгоритм получения соли в android приложении.Все так?Или где-то дырка

Answer 1

[Rsa97]

Security through obscurity - наихудший вариант. Передавайте пароль через защищённое соединение и не извращайтесь.
А дырка в том, что если кто-то может перехватить пароль, то он может с тем же успехом перехватить и кэш, этого будет достаточно для аутентификации.

Comments

[StynuBlizz]

Видимо нужно было уточнить что все это передаеться через https

[StynuBlizz]

По сути я присваиваю хэшу дополнительную соль что поможет если взламают БД,соответственно радужные таблицы не помогут так как не известна изначальная соль

[Rsa97]

StynuBlizz: А зачем мне полностью ломать пароль, если достаточно найти пересылаемый хэш? То есть всё равно будет работать только хэширование на серверной части.

[StynuBlizz]

А как его найти если все пересылается по https?

[StynuBlizz]

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

[Rsa97]

StynuBlizz: А как найти пароль, если он пересылается по https? Зачем его дополнительно хэшировать не клиенте?

Answer 2

[xmoonlight]

Смотрите на реализацию CRAM-MD5
(вместо MD5, ставите любую более "устойчивую" hash-функцию)

нужно будет узнать алгоритм получения соли в android приложении.Все так?Или где-то дырка

именно в этом и дырка, что достать алгоритм из приложения - проще простого!

Answer 3

[_ _]

В этом нет никакого смысла - шлите сам пароль через https и все.

Comments

[xmoonlight]

Всё, что идёт через https через чужой центр сертификации - защищено лишь частично: от некой большей части людей, не имеющих доступа к авторизованному центру сертификации.
Необходимо ВСЕГДА! защищать (шифровать) трафик своими силами в любом случае и никогда не надеяться на инкапсуляцию.

[_ _]

xmoonlight: т.е. в ситуации с хешированием паролей это значит тащить на клиент production secret? Ну флаг вам в руки

[xmoonlight]

Александр Марченко: значит, что вы недостаточно информированы в данной сфере.

[_ _]

xmoonlight: если у людей есть навыки осуществить man-in-the-middle атаку, да так, чтобы атакуемый ничего не заметил, обойдя certificate pinning, то сделать реверс-инжениринг приложения им не составит никакого труда. Если у вас есть другое мнение и конкретный кейс - вы поделитесь. С удовольствием почитаю статью на хабре.

[StynuBlizz]

Ну сделают они реверс а толку?Исходное значение хэша они то все равно не получат,а получат только алгоритм

[_ _]

StynuBlizz: да сам хэш, который через mitm отловят, отправят на сервер и все! Ну включите уже голову!

Answer 4

[АртемЪ]

Достаточно ли сильной будет такая схема хэширования с двойной солью?

Никакая вообще. С тем же успехом буковки местами можете поменять.

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

Нормальная схема такова - по https передается пароль.
На сервере к паролю добавляется соль, он подвергается хэшированию, и получившийся хэш сравнивают с тем что храниться в БД.

Comments

[StynuBlizz]

По https передаеться хэш пароля,вот тогда это будет стандартной схемой

[АртемЪ]

StynuBlizz: Ни в коем случае.
Какой смысл передавать хэш пароля? Это же просто рушит всю схему
Передается пароль - фраза известная только пользователю.
На сервере хранится его хэш.
Сервер получает пароль хэширует его и сравнивает с хэшем хранящимся в базе.

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

Answer 5

[Дмитрий]

алгоритм получения соли в android приложении при желании можно узнать.