Hellsy22 Aug 24 2017 at 13:12

И еще раз о 320 миллионах паролей

3 min

18K

Information Security*

+15

Comments 17

chig00 Aug 24 2017 at 13:39

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

AndrewRo Aug 24 2017 at 14:20

Если его нет в базе — это не значит, что он хороший. Например, пароль ms8u в базе не нашёлся, хотя подобрать его по хешу — раз плюнуть.

demist Aug 24 2017 at 14:51

кажется, что этого chig00 и не утверждал.
а то получается, что раз коровы дают молоко, то значит все, кто дает молоко — коровы

NINeOneone Aug 25 2017 at 09:56

Почему его раз плюнуть подобрать по хэшу?

AndrewRo Aug 25 2017 at 09:57

Да, потому, что он состоит из 4 символов.

NINeOneone Aug 25 2017 at 11:08

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

AndrewRo Aug 25 2017 at 11:12

Либо с помощью радужных таблиц.

-1

sic Aug 25 2017 at 00:21

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

Hellsy22 Aug 25 2017 at 06:20

Сервер не знает какой именно из последних 64(иногда 32) хешей подошел и подошел ли хотя бы один из них. Вот ниже предлагают ограничиться двумя запросами (по 512 хешей соотв.), но это увеличит нагрузку на сервер в ~5.3 раза и боюсь, что это уже будет ощутимо.

sic Aug 25 2017 at 14:45

Да, в целом все-таки, если, как предлагали, использовать Tor, то вполне секьюрное решение. Плюсую.

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

vitaliy2 Aug 25 2017 at 06:13

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

Например, если мы хотим уложиться в 2 запроса, придётся передавать по 396 хэшей (9.28 КБ на запрос при передаче в бинарном виде несж.).

3 запроса — 54 хэша (1.27 КБ)
4 запроса — 20 хэшей (480 байт)

ksgr Aug 25 2017 at 06:13

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

Hellsy22 Aug 25 2017 at 06:26

Если есть пара IP/пароль, то, имея на руках различные базы, с некоторой вероятностью можно найти и почтовый адрес (или набор потенциальных адресов), на который пользователь регистрировался на многочисленных ресурсах. А на оригинальном ресурсе почтовый адрес вообще предлагали оставить «для уведомления».

fedorro Aug 25 2017 at 08:32

Если есть Tor Browser, то он ни ИП, ни другой информации не выдаст — всё подменяется на сколько возможно.

Hellsy22 Aug 25 2017 at 10:40

Комплексные меры безопасности всегда лучше, я с этим не спорю.

vitaliy2 Sep 2 2017 at 11:06

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

Как результат, сервис передающий хэш, не может заслуживать никакого доверия. Исключение составят только полностью рандомные пароли от 15 символов, составленные по 95-символьному словарю, или аналогичные им.

vitaliy2 Sep 2 2017 at 11:15

Будет иметь смысл если знать логин и от какого сервиса пароль

Да, Вы правы. Но тогда скиньте мне все Ваши пароли, я ведь всё-равно не знаю ни логин, ни от каких сервисов они.

Show the best of all time