Это из-за того что плагины теперь в отдельном процессе, соответственно настройки микшера выставленные Опере тому же флешу получаются теперь не указ. Как вариант, попробуйте отловить в микшере процесс плагина.
В чём нет смысла? Процитирую вас:
>поэтому как-то совсем не выигрышно, ну будет 2 польз. с разной солью, но одинаковыми паролями и что? зная алгоритм как соль применяется в пароле тут они абсолютно ничем не защищены.
В среднем пользователи будут защищены лучше, т.к. что бы взломать эти два пароля злоумышленнику придётся брутфорсить в два раза дольше, а значит стоимость взлома одного пароля станет больше, что равнозначно лучшей защищённости паролей в данной схеме.
Упреждая уже приевшуюся риторику: когда говорят о схемах защиты и соления подразумевается что защищается вся база целиком, а не какой-то отдельный пользователь. Для защиты одного пользователя соли мало спасают, в т.ч. и ваши «динамически генерируемые», единственный путь здесь это использовать медленные хеш-функции.
В любом случае, будьте подробны обозначить свою позицию поподробней, иначе мне уже совершенно непонятно что вас не удовлетворяет в обсуждаемых схемах и к чему у вас есть претензии.
Для полностью скомпрометированной системы (слиты дамп БД и исходники) ваше «динамически вычисляемая» соль не будет ничем отличаться от соли хранимой рядом с результирующим хешем. Тем не менее, да, как дополнительный ступень усложнения жизни злоумышленника это имеет право на жизнь, примерно это я и описывал в идеальной на мой взгляд схеме.
зная соль и алгоритм можно тупо перебирать по таблицам так же как и всегда.
Для вас радужные таблицы это что-ли какая-то магия? Почитайте хотя-бы вот этот раздел на вики. Я посмотрю как вы будете составлять таблицу для строк у которых длина больше 20 символов в которые входит длинное случайное сочетание символов и особенно мне интересно откуда вы достанете столько памяти.
Вы в курсе что такое хеш-функция? Зная хеш вы не можете эффективно узнать входное значение, в идеале вы можете сделать это не быстрее чем тупым перебором, это так называемая односторонняя функция, краеугольный камень современной криптографии.
Так что вы знаете алгоритм и соль, но это вам никак не поможет избежать перебора для нахождения пароля. Так что в случае 2 вам достаточно подобрать пароль у одного пользователя и вы автоматически узнаете пароли у всех пользователей использовавших этот пароль. В случае же 3 вам придётся брутфорсить для каждого пользователя отдельно, посему скорость узнавания паролей катастрофически снижается.
Фокус заключается в том, что при грамотной настройке сервера и тем более при разносе приложения и БД на разные сервера, вероятность того что вместе с базой стащат ещё и приложение достаточно мала. Т.е. скажем если база была сдамплена через SQL-injection или через доступ к серверу БД, то почти наверняка это означает, что у злоумышленника нет доступа к самому приложению. Поэтому мне кажется что усложнение с секретным ключом в конфигах достаточно весомо и им не стоит пренебрегать.
Одинаковая для всех пользователей соль плоха тем, что у пользователей с одинаковым паролем будет одинаковый результирующий хеш, поэтому даже не зная соли можно будет провести атаку опираясь на самые частые хеши, т.е. например указывать всякие qwerty и password в работающую систему, тем самым можно будет в достаточно краткие сроки подобрать пароль для дочтаточно большого числа аккаунтов.
А вообще мне интересно узнать как дела с брутфорсом обстоят у SRP, по идее именно он будет надёжнее всего, т.к. не только нельзя восстановить пароль имея базу и соль у всех пользователей разная, но и как таковой передачи пароля на сервер не происходит. Единственный недостаток, что он требует от клиента отдельных телодвижений, т.е. в случае веба придётся ещё использовать при авторизации клиентский джаваскрипт.
На данный момент, лично мне, самым надёжным вариантом кажется следующий: в конфигах приложения хранится секретный ключ, когда требуется получить соль к секретному ключу примешивается неизменяемая информация пользователя (ник, идентификатор, время регистрации и т.д.) и берётся хеш функция (здесь подойдёт и md5), с этой солью мы хешируем пароль «медленной» хеш функцией, подбирая медленность из соображений желаемого соотношения надёжность/производительность.
Т.е. в итоге соль будет у всех пользователей разная, если злоумышленник получит только базу, то сделать с ней он ничего не сможет, если же он завладеет и базой и секретным ключом, то он не сможет эффективно проводить атаки брутфорсом и по словарю не только из-за разной у всех пользователей соли, но и из-за удручающей медленности конечной хеш-функции.
Так никто же вас не заставляет выполнять рекомендации буква в букву, вы спокойно можете уменьшить время расчёта хеша до 0.1-0.01 секунды изменив всего одну константу. Мне тоже кажется пассаж про 0.1 секунду на лучшем GPU излишне параноидальным, тем не менее использование bcrypt'а со встроенной солью с числом раундов 10 (0.1 секунды на моём ноутбуке) мне кажется более надёжным и оправданным нежели использование md5 с накрученным поверх своим или чужим солением. Думаю вы согласитесь, что для взломщиков для взломщиков есть большая разница побрутфорсить или атаковать по словарю день-два или же ждать больше года.
У вас эти 100 пользователей будут постоянно логиниться и регистрироваться, что бы мигом заваливать сервер? Скажем хеш будет считаться секунду, и вы как пользователь ресурса будете перелогиниваться скажем раз в неделю, тогда получаем, что такой сервер спокойно выдержит 7*24*60*60≃600к пользователей. По мне так более чем неплохой запас.
Разумеется некоторые проблемы могут возникнуть если на сервере начнёт регистрироваться больше одного пользователя в секунду, но в этом случае спасёт либо многоядерный сервер (всё-равно при такой популярности надо будет апгрейдить сервер), либо временное уменьшение сложности на время пиковой нагрузки. С ддосами же можно бороться введением каптчи на множество попыток логина с одного IP и при увеличенной нагрузке, либо опять же временным уменьшением сложности хеша.
Нам срочно требуется более продвинутая модель параллельного программирования чем та, что предлагают современные языки. Об этом подробнее я скажу в другой статье.
Будете ли вы переводить эту «другую статью»? было бы интересно её почитать. В крайнем случае, можете просто указать в тексте ссылку на неё?
Мне кажется, что проблема описанная в статье в частности привела сегодня к развитию языков использующих акторы, которые позволяют писать очень многопоточные приложения достаточно легко по трудозатратам, только жалко что мейнстримом они таки не спешат становиться. Плюс мне очень бы хотелось что бы возродилось незаслуженно забытое на рубеже 90-х dataflow программирование, которое тоже позволяет достаточно легко писать очень многоптоточные приложения, вплоть до того что встаёт проблема слишком сильной параллельности (fine-grained).
P.S.: На будущее, есть специальный тип поста, называется «перевод».
ID-Based напоминает идеальную почтовую систему: если Вы знаете чье-то имя и адрес, Вы можете отправить ему сообщение, и прочитать это сообщение сможет только он. Также Вы можете удостовериться в его подписи, так как только получатель сможет ее воспроизвести.
Есть маааленькая оговорочка. Подпись сможет сгенерировать не только её обладатель, но и доверенный центр. А если мы говорим о том что бы применять это в целях идентификатора гражданина, то соответственно Самый Главный Ключ будет принадлежать государству, а значит в целях борьбы с экстремизмом оно сможет творить что угодно, подписывая и читая чужие документы, возможно даже юридически значимые.
Так что мой внутренний параноик смотрит на эту систему несколько недоверчиво.
Интересно узнать разность в энергопотреблении включенного компьютера в режиме простоя и с полной нагрузкой на процессор. Неоднократно слышал, что в последнем случае энергопотребление возрастает максимум на 25-30%, хотелось бы проверить данный миф.
>поэтому как-то совсем не выигрышно, ну будет 2 польз. с разной солью, но одинаковыми паролями и что? зная алгоритм как соль применяется в пароле тут они абсолютно ничем не защищены.
В среднем пользователи будут защищены лучше, т.к. что бы взломать эти два пароля злоумышленнику придётся брутфорсить в два раза дольше, а значит стоимость взлома одного пароля станет больше, что равнозначно лучшей защищённости паролей в данной схеме.
Упреждая уже приевшуюся риторику: когда говорят о схемах защиты и соления подразумевается что защищается вся база целиком, а не какой-то отдельный пользователь. Для защиты одного пользователя соли мало спасают, в т.ч. и ваши «динамически генерируемые», единственный путь здесь это использовать медленные хеш-функции.
В любом случае, будьте подробны обозначить свою позицию поподробней, иначе мне уже совершенно непонятно что вас не удовлетворяет в обсуждаемых схемах и к чему у вас есть претензии.
Для вас радужные таблицы это что-ли какая-то магия? Почитайте хотя-бы вот этот раздел на вики. Я посмотрю как вы будете составлять таблицу для строк у которых длина больше 20 символов в которые входит длинное случайное сочетание символов и особенно мне интересно откуда вы достанете столько памяти.
Так что вы знаете алгоритм и соль, но это вам никак не поможет избежать перебора для нахождения пароля. Так что в случае 2 вам достаточно подобрать пароль у одного пользователя и вы автоматически узнаете пароли у всех пользователей использовавших этот пароль. В случае же 3 вам придётся брутфорсить для каждого пользователя отдельно, посему скорость узнавания паролей катастрофически снижается.
Т.е. в итоге соль будет у всех пользователей разная, если злоумышленник получит только базу, то сделать с ней он ничего не сможет, если же он завладеет и базой и секретным ключом, то он не сможет эффективно проводить атаки брутфорсом и по словарю не только из-за разной у всех пользователей соли, но и из-за удручающей медленности конечной хеш-функции.
Разумеется некоторые проблемы могут возникнуть если на сервере начнёт регистрироваться больше одного пользователя в секунду, но в этом случае спасёт либо многоядерный сервер (всё-равно при такой популярности надо будет апгрейдить сервер), либо временное уменьшение сложности на время пиковой нагрузки. С ддосами же можно бороться введением каптчи на множество попыток логина с одного IP и при увеличенной нагрузке, либо опять же временным уменьшением сложности хеша.
Будете ли вы переводить эту «другую статью»? было бы интересно её почитать. В крайнем случае, можете просто указать в тексте ссылку на неё?
Мне кажется, что проблема описанная в статье в частности привела сегодня к развитию языков использующих акторы, которые позволяют писать очень многопоточные приложения достаточно легко по трудозатратам, только жалко что мейнстримом они таки не спешат становиться. Плюс мне очень бы хотелось что бы возродилось незаслуженно забытое на рубеже 90-х dataflow программирование, которое тоже позволяет достаточно легко писать очень многоптоточные приложения, вплоть до того что встаёт проблема слишком сильной параллельности (fine-grained).
P.S.: На будущее, есть специальный тип поста, называется «перевод».
Есть маааленькая оговорочка. Подпись сможет сгенерировать не только её обладатель, но и доверенный центр. А если мы говорим о том что бы применять это в целях идентификатора гражданина, то соответственно Самый Главный Ключ будет принадлежать государству, а значит в целях борьбы с экстремизмом оно сможет творить что угодно, подписывая и читая чужие документы, возможно даже юридически значимые.
Так что мой внутренний параноик смотрит на эту систему несколько недоверчиво.
Он самый. :)
>Замечательный был курс!
Полностью согласен! И не только сам курс, но и в первую очередь преподаватель.