Кстати, о паролях

Мне тут вчера о паролях напомнили.. Так у меня вопрос есть про хранение пользовательских паролей на сервере.

Обычным способом является хранение хэша от пароля с приклеенной солью и самой соли открытым текстом. Иногда ещё используется дополнительная соль,  индивидуальная для экземпляра системы. Но суть в том, что хэш от всего этого считается один раз.

А в одном из веб-движков используется такая схема: hash(hash(password) . salt).

Вопрос: в чём смысл двойного хэширования?

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

С точки зрения подбора пароля по известному хэшу и соли – да, трудоёмкость операции увеличивается вдвое, но стоит ли овчинка выделки?

Умный человек ivlad предположил, что это делается для защиты от атаки с помощью предварительно рассчитанных “недохэшей”. Скажем, для мд5 длина блока данных 512 бит (64 байта). А пароли, даже вместе с солью, обычно сильно короче. Соответственно, при однократном хэшировании большая часть блока данных имеет известные значения, что позволяет применять некоторые атаки, сокращающие время подбора. А при использовании вышеуказанной схемы для второго хэширования будет взято 16 байт данных (или 32, если использовать текстовое представление) + соль. Всё ж побольше первоначального пароля. Фактически это получилась такая зачаточная PBKDF, увеличивающая длину ненулевых данных перед финальным хэшированием. Закат солнца вручную вместо использования проверенного профессионалами способа.

А ещё у кого-нибудь есть мысли, зачем это могло быть сделано?

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Пост лютой ненависти

$ perl -c foo.pl
Can't load '/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/mysql/mysql.so' for module DBD::mysql: libmysqlclient.so.16: cannot open shared object file: No such file or directory at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
at foo.pl line 13

$ ldd /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/mysql/mysql.so
libmysqlclient.so.16 => not found
libz.so.1 => /usr/lib64/libz.so.1 (0x00002ab0ecda9000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ab0ecfbd000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ab0ed1f6000)
libm.so.6 => /lib64/libm.so.6 (0x00002ab0ed40e000)
libc.so.6 => /lib64/libc.so.6 (0x00002ab0ed691000)
/lib64/ld-linux-x86-64.so.2 (0x0000003617800000)

Вот как, блядь, надо было поставить mysql, чтобы добиться такого эффекта? А он ведь как-то поставлен, без него бы DBD::mysql не поставился.

Уроды криворукие

Upd. mysql  за каким-то хуем поставлен из исходников и располагается в /opt. В ld.so.conf про это, понятное дело, никто не написал. Зато написали туда вот такую прелесть:

include ld.so.conf.d/*.conf
include /opt/oracle
include /lib
include /lib64
include /usr/lib
include /usr/lib64
include /opt/informix/lib

Как оно вообще до сих пор работало..

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме