?

Log in

 
 
04 December 2013 @ 06:31 pm
оказывается в браузерах беда с хэшированием  
Разрабочик мотивирует передачу пароля plain text (по ssl каналу) тем, что оказывается ничего кроме md5 в браузерах нету и он не хочет чтобы хэшики генерировали клиенты, поскольку в случае кривой реализации алгоритма хэширования на некоторых клиентах он огребёт проблем. По его словам в браузерах ничего лучше md5 пока не стандартизовали в том, что можно вынести на клиента.

update: реально важный аргумент разработчика в том, что выбрав bcrypt он увидел генерацию хэша в браузере порядка минуты (12 раундов). Проверил штатным браузером на Android 2.2 на стареньком huawei - 2 минуты 10 секунд реализацией javascript-bcrypt на googlecode. При учёте что везде и так ssl никто не готов ждать логина так долго.
 
 
 
Slach: just nice php programmerslach on December 4th, 2013 03:33 pm (UTC)
ну так то да, формально разработчег прав
www.w3.org/TR/WebCryptoAPI/
формально это все еще WorkingDraft ...
но блиа... нормальных реализаций вроде вполне себе достаточно

а что подразумевается под словом "кривая реализация"?
в смысле на клиенте и на сервере разные sha256 что-ли будут?
или подсаливать он тоже на клиенте собрался? =)
grey_olli: bwgrey_olli on December 4th, 2013 04:26 pm (UTC)
разные хэшики в разных клиентах.

Кстати без соли отдавать 8ми символьные пароли в силу наличия rainbow tables безопаснее не станет.

Разве что пропадёт возможность случайно записаться в какие нибудь логи (например в логи очереди на создание пользователя).
Slach: just nice php programmerslach on December 5th, 2013 03:17 am (UTC)
"разные хэшики в разных клиентах. "
это вообще даже не знаю как относиться...

PureJS алгоритмы реализованы на базовых структурах данных... это не селекторы какие нибудь и не DOM, CSS

реализация Array и Object одинаковая везде...

пусть возьмет какой ниюудь sha-256 и попробуем найти браузер в котором это "будет работать по другому"...
grey_olligrey_olli on December 5th, 2013 09:42 am (UTC)
см. update.
Oleksandr Nikitin: photo24wizzard0 on December 4th, 2013 06:02 pm (UTC)
что за бред? куча хешей есть, и даже SRP есть
grey_olli: bwgrey_olli on December 4th, 2013 09:49 pm (UTC)
Пожалуй выведу я эту дискуссию в паблик и скину линк разработчику. Ну и соответственно если он аргументирует свою линию более подробно - отпишу тут в комментариях или апдейтом к посту.
grey_olligrey_olli on December 5th, 2013 09:43 am (UTC)
см. update
Oleksandr Nikitin: photo24wizzard0 on December 5th, 2013 09:12 pm (UTC)
Значит, реализация ебнутая. Я видел много ебнутых реализаций.

Например, одна библиотека считает diffie-hellman за 35 секунд, а другая (с той же длиной ключей) за 0.08 секунды.

И, в целом, когда мало CPU, мало батарейки, а у атакующих на дворе ASIC'и, считающие даже для bcrypt миллионы хешей в секунду - хеширование подход не ахти какой правильный, надо использовать интерактивные протоколы, они дают сходную степень безопасности гораздо меньшей кровью.
Slach: just nice php programmerslach on December 5th, 2013 10:14 am (UTC)
ладно, я видимо действительно нихрена не понимаю в безопасности...
bcrypt ... на клиенте...
grey_olli: bwgrey_olli on December 5th, 2013 12:26 pm (UTC)
Если с клиента отправлять на сервер не plain text, а хэшики, то хэшики должны быть сделаны тем же алгоритмом что и на сервере.

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

В итоге из-за того что bcrypt / 12 rounds считается некоторыми клиентами медленно, то отправляем plain text (как почти у всех, кстати) поверх ssl канала (то есть теоретически - защищённого).
Oleksandr Nikitin: photo24wizzard0 on December 5th, 2013 09:13 pm (UTC)
я лично считаю, что bcrypt надо было использовать до 2010 года, а сейчас если у них претензия на секьюрити и хочется думать что трафик могут перехватить - то только разнообразные challenge-response, других путей нет.
Oleksandr Nikitin: photo24wizzard0 on December 5th, 2013 09:18 pm (UTC)
> и переделывать не будут если его внезапно не научатся дербанить на коллизии.

а какая простите модель атакующего?

дело в том, что если мы считаем что плейнтекст по SSL плохо, то и bcrypt одинаково плохо, потому что можно же тупо авторизироваться перехваченным хэшом, и ничего считать не надо