возможно, это намек на отсутствие «восходящей» ветки в этих регионах, и соответственно невозможность обеспечения связи. В коробочке, видимо, живет сотовый модемчик.
согласен, реальный словарь может быть в несколько тысяч слов, время перебора достаточно большое.
всё же почитайте результаты исследований, ссылку я давал выше, это может оказаться интересным.
ну дык, я беру 500 слов, а не 2000, это 2^9 вместо 2^11 комбинаций на слово, 4 слова в фразе дают тогда 2^36 вместо 2^44, и перебирать — на видеокарте.
ProgerXP привел данные, что словарь современной газеты содержит 600 слов, я с ним согласен, но оценку времени перебора это сильно не изменит.
и языки разные — это как минимум требует информации о том человеке/ресурсе, от которого пришёл хэш. А если это массовая дыра, как на Adobe? Как вы определите, кто из пользователей кем работает и где?
Это да. Я имел в виду подбор пароля к роутеру. Или подбор пароля при известной жертве — взлом под заказ, так сказать.
Это всё равно лучше, чем просто набор букв и цифр. Сейчас, когда в паролях используют только латиницу и спецсимволы в случайном порядке — их можно перебрать брутфорсом, гарантированно
В перспективе двух ближайших лет это (без дополнительного усложнения) ничем не лучше, т.к. по мере увеличения распространенности таких паролей появятся и словари и алгоритмы под них.
В новостях я уже читал про то, что какой-то эксперт продемонстрировал нестойкость паролей из нескольких слов. (на русском найти не могу, вот ссылка на английском). Там, кстати, в последнем абзаце резюмируется, что при большой аудитории даже при использовании 5 слов, у 50% людей стойкость пароля оказывается эквивалентной 30-битному паролю (2^30 чуть больше миллиарда). Это статья 2012 года. Что я там говорил про перспективу? — Забудьте, словари уже должны быть.
а самое печальное, что пароли из русских букв (т.е. слов) практически нигде не разрешаются. А если вводить русские буквы по английской раскладке — то «б» и «ю» попадают на "<" и ">", которые обычно запрещены.
А хакеры у нас ведь глупее, чем обычные люди, правда?
И про Яндекс-клавиатуру они не узнают никогда-никогда?
Ребята, через годик у всех хакеров будут словари для русских раскладок. Яндекс — не виноват, они просто сделали удобный ввод. Плохо, что Яндекс рекламирует надежность таких паролей.
Проблема не в том, какой пароль назначает IT специалист, проблема в том, какой пароль назначает обычный человек.
Я с детства помню соотношение «словарный запас Шекспира 20000 слов, а словарный запас любого номера газеты Times — 200 слов», может мои данные и устарели, но обычный человек использует от силы тысячу слов, а легко-запоминаемыми считает, думаю, как раз 200. Ну пусть 500.
И вот наша оценка сокращается до 500^4=6.25E10, аналогично 10-значному числовому паролю, который в посте признан моветоном.
Еще раз повторяю, речь о пароле, который назначит обычный человек.
Насчет разных языков — не забывайте, что у атакующего зачастую более выгодная позиция, и он может знать весьма точно язык (языки, включая и профессиональные жаргоны) жертвы, и отбрасывать словари ненужных языков.
И вообще — против алгоритмов перебора нужно бороться алгоритмами создания паролей. Давно уже нужно сформулировать алгоритм создания по настоящему стойких паролей. И доверить это нужно профессионалам, а то обычные админы как ни пытаются, толку пока нет.
Ведь не составит труда добавить «соль» и в пароль — значок "#" «где-то» в середине одного из слов пароля заставит обломаться атаку по словарю, но это же алгоритм, это же нужно описать. А пока у нас только чудесная картинка «correct horse battery stapple», без намека на невысокую сложность такого пароля при атаке по словарю, без намека на добавление каких-нибудь символов.
В следующем посте я хочу рассказать о тепловых расчётах головки принтера, почему их такими делают и как избежать образования пробок. У меня даже сложилось впечатление, что я теперь смогу вполне осознанно выбирать размеры, радиаторов, термобарьеров и прочее. Буду рад если сообщество поучаствует на предмет поиска возможных ошибок и заблуждений
Да уж. Будем посмотреть. Давай, не затягивай со второй частью. Редко попадаются интересные задачки по теплообмену, а твоя, так, похоже, просто конфетка.
Вот, кстати, еще парочка замечаний:
При выборе платформы (ну, в данном случае было наоборот, взяли готовую заготовку, но вы понимаете, о чем я) нужно же закладывать некоторый запас по ресурсам? Так вот, запас по «latency» — такой же ресурс как объем памяти или MIPS. И нужно помнить об этом запасе при рассмотрении каждого нового требования или хотелки. Это, кстати, через годик становится весьма ценным куском опыта, т.к. появляется возможность до начала реализации фичи прикинуть в уме (по нескольким ранее реализованным или отклоненным) и сказать на раннем этапе — «мы не помещаемся в запас по latency», сэкономив немножко времени на прототипировании. Даже один такой аргументированный ранний отказ — это конкретный профит и он обычно приветствуется окружающими.
Появляется и дополнительный аргумент для неиспользования кривых алгоритмов — если алгоритм пожрал 80% запаса по какому-то из ресурсов (как, например, в приведенном псевдокоде — пожрал 100% latency), то, ясен перец, второй подобный алгоритм уже не запихаешь, да и более скромные алгоритмы уже не добавишь.
если требуется ответ коллективного разума на вопрос «можно ли совместить фазовое управление мощностью с ограничением задержки в 65мкс» — то ответ «ДА» (но это и в посте написано).
если требуется ответ на вопрос «как конкретно реализовать совместную работу фазового управления и уложиться в 65мкс задержек» — то мой опыт — аппаратный детектор нуля на выпрямителе, потом прерывание с контролем правильности длительности полупериода (упрощенный подавитель дребезга), в котором взводится таймер на заданную длительность импульса на открытие триака.
если требуется ответ «обоснован ли отказ от семейства микроконтроллеров из-за недостатка опыта программирования в условиях поджимающих сроков» — ответ для менеджера проекта — «ДА, но программиста пора менять», ответ для программиста — «НЕТ, ты занимаешься этим в том числе для того, чтобы приобрести опыт».
А голосование в конце поста меня окончательно сбило с толку. Короче, ответьте, чего в итоге хочет автор?
while (1) {
Запрет_прерываний;
// определяем момент перехода через 0
// делаем задержку включения
// Включение; Задержка_на включение; Выключение;
// Разрешение прерываний;
// пауза перед началом очередного цикла
};
— это пример несложной задачи и ее неоптимального решения. То, что вы упираетесь в последствия неоптимальности — это нормально, и связано с нормальным ростом требований к устройству.
Выбора у вас, по большому счету — два. Либо оптимизировать алгоритм, либо увеличивать мощность платформы.
В условиях поджимающих сроков второе предпочтительно. Но отдавайте себе отчет, что сам подход с использованием неоптимальных алгоритмов — это плохо.
И не ожидайте, что любой DIY алгоритм может быть перенесен в серийное устройство без глубокой переработки.
Может это получится новый метод защиты от абразивного износа? В т.ч. для гибких (тонких) деталей.
А то сейчас защита в осн. за счет массы, даже материалы типа карбида вольфрама — долго не живут.
Сугубо личное мнение — перевод названия книги не соответствует оригиналу.
Проектирование баз данных. Дизайн и метод
Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design
1. Исключено слово «реляционные»
2. Добавлено слово «метод»
Исходный смысл названия книги -такой
«Проектирование и разработка реляционных баз данных. Нормальным языком»
Cable — сокращение от Cable TV — кабельное телевидение.
Читаем дальше, и становится понятно окончание абзаца — … Двойная победа.
Имеется в виду, что в освободившееся от просмотра телека время можно направить на что-то полезное, может быть даже прибыльное.
Ай, спасибо!
Когда-то день потратил — не нашел, оказывается надо было подождать, пока снимут с поддержки.
Сделаю себе, наконец, FullHD безмятежность без растягивания картинки!
гугл уже выдает кучу ссылок на это таинственное место в новом таинственном и манящем штате Нью Сексико…
всё же почитайте результаты исследований, ссылку я давал выше, это может оказаться интересным.
ProgerXP привел данные, что словарь современной газеты содержит 600 слов, я с ним согласен, но оценку времени перебора это сильно не изменит.
Отличный цикл статей! Спасибо, всё это отличная, хорошо изложенная и ценная для всех нас — читателей информация.
Это да. Я имел в виду подбор пароля к роутеру. Или подбор пароля при известной жертве — взлом под заказ, так сказать.
В перспективе двух ближайших лет это (без дополнительного усложнения) ничем не лучше, т.к. по мере увеличения распространенности таких паролей появятся и словари и алгоритмы под них.
В новостях я уже читал про то, что какой-то эксперт продемонстрировал нестойкость паролей из нескольких слов. (на русском найти не могу, вот ссылка на английском). Там, кстати, в последнем абзаце резюмируется, что при большой аудитории даже при использовании 5 слов, у 50% людей стойкость пароля оказывается эквивалентной 30-битному паролю (2^30 чуть больше миллиарда). Это статья 2012 года. Что я там говорил про перспективу? — Забудьте, словари уже должны быть.
И про Яндекс-клавиатуру они не узнают никогда-никогда?
Ребята, через годик у всех хакеров будут словари для русских раскладок. Яндекс — не виноват, они просто сделали удобный ввод. Плохо, что Яндекс рекламирует надежность таких паролей.
Я с детства помню соотношение «словарный запас Шекспира 20000 слов, а словарный запас любого номера газеты Times — 200 слов», может мои данные и устарели, но обычный человек использует от силы тысячу слов, а легко-запоминаемыми считает, думаю, как раз 200. Ну пусть 500.
И вот наша оценка сокращается до 500^4=6.25E10, аналогично 10-значному числовому паролю, который в посте признан моветоном.
Еще раз повторяю, речь о пароле, который назначит обычный человек.
Насчет разных языков — не забывайте, что у атакующего зачастую более выгодная позиция, и он может знать весьма точно язык (языки, включая и профессиональные жаргоны) жертвы, и отбрасывать словари ненужных языков.
И вообще — против алгоритмов перебора нужно бороться алгоритмами создания паролей. Давно уже нужно сформулировать алгоритм создания по настоящему стойких паролей. И доверить это нужно профессионалам, а то обычные админы как ни пытаются, толку пока нет.
Ведь не составит труда добавить «соль» и в пароль — значок "#" «где-то» в середине одного из слов пароля заставит обломаться атаку по словарю, но это же алгоритм, это же нужно описать. А пока у нас только чудесная картинка «correct horse battery stapple», без намека на невысокую сложность такого пароля при атаке по словарю, без намека на добавление каких-нибудь символов.
Уфф. Наболело.
Да уж. Будем посмотреть. Давай, не затягивай со второй частью. Редко попадаются интересные задачки по теплообмену, а твоя, так, похоже, просто конфетка.
Вот, кстати, еще парочка замечаний:
При выборе платформы (ну, в данном случае было наоборот, взяли готовую заготовку, но вы понимаете, о чем я) нужно же закладывать некоторый запас по ресурсам? Так вот, запас по «latency» — такой же ресурс как объем памяти или MIPS. И нужно помнить об этом запасе при рассмотрении каждого нового требования или хотелки. Это, кстати, через годик становится весьма ценным куском опыта, т.к. появляется возможность до начала реализации фичи прикинуть в уме (по нескольким ранее реализованным или отклоненным) и сказать на раннем этапе — «мы не помещаемся в запас по latency», сэкономив немножко времени на прототипировании. Даже один такой аргументированный ранний отказ — это конкретный профит и он обычно приветствуется окружающими.
Появляется и дополнительный аргумент для неиспользования кривых алгоритмов — если алгоритм пожрал 80% запаса по какому-то из ресурсов (как, например, в приведенном псевдокоде — пожрал 100% latency), то, ясен перец, второй подобный алгоритм уже не запихаешь, да и более скромные алгоритмы уже не добавишь.
А голосование в конце поста меня окончательно сбило с толку. Короче, ответьте, чего в итоге хочет автор?
— это пример несложной задачи и ее неоптимального решения. То, что вы упираетесь в последствия неоптимальности — это нормально, и связано с нормальным ростом требований к устройству.
Выбора у вас, по большому счету — два. Либо оптимизировать алгоритм, либо увеличивать мощность платформы.
В условиях поджимающих сроков второе предпочтительно. Но отдавайте себе отчет, что сам подход с использованием неоптимальных алгоритмов — это плохо.
И не ожидайте, что любой DIY алгоритм может быть перенесен в серийное устройство без глубокой переработки.
Я думал, вы решение проблемы ищете…
habrahabr.ru/company/infostart/blog/217369/
брут-форс решение задачи о рюкзаке с помощью SQL. Только без учета ценности, но мне кажется, это можно доработать.
А то сейчас защита в осн. за счет массы, даже материалы типа карбида вольфрама — долго не живут.
Проектирование баз данных. Дизайн и метод
Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design
1. Исключено слово «реляционные»
2. Добавлено слово «метод»
Исходный смысл названия книги -такой
«Проектирование и разработка реляционных баз данных. Нормальным языком»
Читаем дальше, и становится понятно окончание абзаца — … Двойная победа.
Имеется в виду, что в освободившееся от просмотра телека время можно направить на что-то полезное, может быть даже прибыльное.
Когда-то день потратил — не нашел, оказывается надо было подождать, пока снимут с поддержки.
Сделаю себе, наконец, FullHD безмятежность без растягивания картинки!