найдите ошибку в коде

yroslavasako

Тут рекламировали одну
тулзу для генерации паролей для сайтов



#!/bin/bash



read -srp 'Password: ' master

domain=$(echo $1 | tr A-Z a-z)

length=${2:-10}



hash=$master:$domain



i=0

while true

do

	hash=$(echo -n "$hash" | openssl md5 -binary | base64 | tr +/= 98A)

	i=$(($i + 1))

	if [ $i -lt 10 ]

	then

		continue

	fi

	valid=$(echo "${hash:0:$length}" | egrep '^[a-z]' | egrep '.[A-Z]' | egrep '.[0-9]' )

	if [ "$valid" != "" ]

	then

		break

	fi

done

echo ${hash:0:$length}

Вам ничего странным не кажется?

Dasar

Из странного: язык дурацкий, убивает читабельность и вынуждает стрелять из пушек по воробьям.
В целом, имхо, понятно что делается.
Сгенерили хэши, порезали каждый, слили первые 10 в утиль. выбрали первый, который подошел под формат.

zya369

в каком смысле "генерации"?
если просто рандом нужен, то зачем master читать?
странным кажется то, что кто-то написал что-то для сайта на шелле :grin:

YUAL

Автор извращенец

#!/bin/bash
read -srp 'Password: ' master
domain=$(echo $1 | tr A-Z a-z)
length=${2:-10}
hash=$master:$domain
echo $hash | md5sum | base64 | head -c $length
echo

salamander

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

Marinavo_0507

там ещё убираются спецсимволы (оно и понятно, не все сайты разрешают их)
и зачем base64 после md5sum (вывод которого и так весь из печатных символов)?

salamander

Увеличить алфавит символов с 16 до 64. Впрочем с точки зрения подбора пароля по символам это будет только видимость улучшения надежности (если знаешь первые K симовлов, то K+1 уже может быть не любым). Собственно поэтому в оригинальной генерилки используется бинарный вывод.

YUAL

там ещё убираются спецсимволы

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

YUAL

Впрочем с точки зрения подбора пароля по символам это будет только видимость улучшения надежности (если знаешь первые K симовлов, то K+1 уже может быть не любым).

Ну не совсем так. Оно улучшает надёжность, если взломщик не знает что в качестве пароля используется base64, тоесть в 99% случаев.

yroslavasako

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

представь что его передают как часть URL.

yroslavasako

Ну не совсем так. Оно улучшает надёжность, если взломщик не знает что в качестве пароля используется base64, тоесть в 99% случаев.

security from obscurity. Фуууууууу.

salamander

В криптографии как-то не принято полагаться на то, что злоумышленник не знает алгоритм.
Но с другой стороны все это не важно. Тут мы защищаемся от случая когда по раздолбайству админов ресурса твоя и не только пара логин-пароль утекли к злоумышленнику. Теперь злоумышленник выполняет простейшие атаки на эту базу с целью нарыбачить себе немножко паролей незадачливых пользователей. Под простейшие атаки я понимаю следующее:
1) Если пароли хранятся в хэшированном виде - то словарная атака с целью восстановления текстового значения пароля.
2) После идем с логином и текстовым паролем на другие ресурсы и пытаемся угнать там аккаунты.
Любая разумная хэш-функция от пары пароль-домен защищает от этой атаки. Так что можно даже base64 не делать. Но с ней результирующий пароль выглядит солиднее.

PS: анализировать более сложные атаки мне компетенции в вопросе не хватает; да и кому я нафиг сдался, чтобы против меня что-то серьезное затевать.

Marinavo_0507

язык дурацкий, убивает читабельность

как это будет на powershell или что там сейчас в моде?

evgen5555

Кстати.
У него в репозитории есть controllable query на питоне:
http://github.com/lanzz/sqlbuilder

YUAL

представь что его передают как часть URL

Пиздить.

YUAL

В криптографии как-то не принято полагаться на то, что злоумышленник не знает алгоритм.

спасибо, капитан. Айвенго вон уже предсказуемо срегировал (перепутав from и through правда)
Только в данной ситуации безопасность через неизвестность не выступает основным фактором безопасности, а просто усложняет жизнь взломщику, который будет работать брутфорсом и не знает алгоритм и упрощает жизнь взломщику, который работает брутфорсом и знает алгоритм. Учитывая вероятность попасть на второго я за base64.

yroslavasako

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

YUAL

Это потому что я не эльф, потому что это херня под баш а значит для полутора калек ну и потому что я уже объяснял почему генерация паролей на основании домена - говно. Хотя последнее скорее наоборот в пользу "стать популярным".

zya369

1) Если пароли хранятся в хэшированном виде - то словарная атака с целью восстановления текстового значения пароля.
Любая разумная хэш-функция от пары пароль-домен защищает от этой атаки.

только надо иметь в виду, что в данном контексте md5 не является разумной

yroslavasako

Так вот, собственно, что меня побудило написать этот пост. Мне тоже дали эту ссылку почитать со словами "гы-гы, смотри какая школота". Я, ожидая подвоха, несколько раз перечитал исходник, не обнаружил ничего криминального, кроме разве что использования баша и не использования резидентной памяти. Не нашёл ошибок, о чём и сообщил своему собеседнику. И обнаружил, что переоценил границы своей компетентности. С криптографией очень легко попасть впросак, некоторых векторов атак я просто не догадался представить, о деталях реализации алгоритмов и текущих абстракциях не знал.
На самом деле ошибка в строчке hash=$master:$domain. Нельзя просто взять конкатенировать мастер пароль с доменом. Пароль становится частью каждого сообщения, что снижает общую стойкость их хешей. Более того, хеш функция, которая потом применяется на эту строчку, имеет состояние, и после кодирования парольной части, это состояние будет общим для всех остальных сообщений. Станет гораздо проще построить коллизии.
Надо было не изобретать собственные криптографические примитивы, а использовать готовые. Эта задача хорошо известна и описана в вики. Там же приведено решение, ссылка на RFC 2104 и объяснение, почему простая конкатенация не канает.
Автор этого криптографического софта не знал основ, изобретал велосипед, и изобрёл хреновый. Я тоже не знал, и полагал, что всё работает. Это несколько смущает, когда думаешь о преимуществе открытого софта, позволяющего вычитывать исходники. Правда тот факт, что кто-то другой нашёл, всё же обнадёживает.
В любом случае, опасайтесь криптографии! Избежать всё равно не выйдет, но можно попробовать придумывать как можно меньше отсебятины.

YUAL

Зачем вообще искать криптографические ошибки в уебищной по свой природе системе генерации паролей на основании доменов?

yroslavasako

а что такого уебищного в этой системе?

yroslavasako

Шифруй дважды. Один раз - номером версии, второй раз - паролем.

YUAL

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

yroslavasako

вот список логинов - это проблема. Можно тоже генерировать. Был такой сервис, который поставлял пустые логины для разных сайтов, как способ бороться против сайтов, прочитать информацию с которых можно только зарегистрированным пользователям. Вот у тебя будет локальная версия. Зашёл на сайт, нужен логин-пароль - пробуешь подставить генерированные. Если не подошли - пробуешь создать. Для форума и прочих критичных паролей не очень. Но в вебе есть очень много некритичных паролей.

YUAL

А для не критичного одноразового говна у меня вообще один пароль. Зачем там что-то генерить?
Таким образом мы приходим к тому что нам надо хранить где-то информацию о логинах и о том что пароль был скомпрометирован (или например ежегодно сменен по правилам безопасности как например в альфабанке) и номер версии. Если у нас есть хранилище, тогда почему бы не выкинуть всю эту хрень с генерацией паролей и просто не пользоваться нормально сгенерёными на основании /дев/рандом паролями. Мы получаем в стопицот раз большую гибкость. Например можно хранить пароли которые тебе дали на попользоваться, можно хранить пинкоды к банковским картам, можно хранить ключи от btsync и т.п.

Marinavo_0507

На самом деле ошибка в строчке hash=$master:$domain. Нельзя просто взять конкатенировать мастер пароль с доменом. Пароль становится частью каждого сообщения, что снижает общую стойкость их хешей. Более того, хеш функция, которая потом применяется на эту строчку, имеет состояние, и после кодирования парольной части, это состояние будет общим для всех остальных сообщений. Станет гораздо проще построить коллизии.

поясни, чем злоумышленнику помогут коллизии :confused:

BatoSan

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

bugmenot.com , но в 90% случаев логины оттуда уже забанены.

carusya

В любом случае, опасайтесь криптографии! Избежать всё равно не выйдет, но можно попробовать придумывать как можно меньше отсебятины.

Сколько раз было сказано, что в большинстве случаев, когда в криптографии изобретается велосипед - этим велосипедом потом прилетит больно в лоб пользователю. Странно, что ты с этим только сейчас столкнулся.
Вот мне понравилось ещё, например.

yroslavasako

ну так какая-то криптография всё равно нужна. В программный продукт её внедряет программист, а не криптограф. Видимо, всем программистам нужен специальный обзорный курс криптографии, построенный не с точки зрения разработки криптоалгоритмов, а с точки зрения использования готовых.
Update. А сейчас таковые в МГУ читаются где-нибудь?

Оставить комментарий