Разного порядка риски: одно дело подсказать подружке пароль ее начальницы (и поди докажи откуда она его узнала), а другое - апдетить запись. Во первых не факт что обычный админ/девелопер сможет обновить хаш (при правильном дизайне - не сможет). Во вторых апдейт оставит всякие прямые и косвенные следы (время обновления, логи, бекапы, и т.д.)
Ключевой момент моей фразы " древнему ". Собственно вся статья об этом. MD5 - мгновенно, bcrypt - чуть дольше.
Собственно есть целая палитра взломщиков и способов. На одном конце спектра есть обычный человек как вы - вы на вашем компьютере ничего особого сделать не сможете (кроме MD5 или совсем коротких паролей завернутых в bcrypt). На другом есть заинтересованные люди побогаче (разведки крупных стран) которые активно эксплуатируют чужие утечки. Между ними целая палитра возможностей.
Это все правда, но не вся правда: соль просто сильно увеличивает стоимость взлома.
При утечке утечет и хеш и соль: взломщик может практически до бесконечно распаралеливать поиск колизии. Просто, для примера, посмотрите в статье скорость поиска для bcrypt (он использует соль).
Вы фундаментально ошибаетесь допуская принятие утечки как данность:
Хороших алгоритмов для хеширования единицы. Криптография - сложная наука и при попытке изобрести свой велосипед вы точно будете в зоне риска. А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее.
Скорость поиска коллизии можно увеличивать практически до бесконечности (распараллеливать на все доступные ресурсы, специализирование ASICи, и.т.д.) да к тому-же все это можно делать незаметно для жертвы.
Не ленитесь: сегодня утечка хешей практичеки такая-же катастрофа как утечка паролей в чистом виде. Тот что лично вы не можете подобрать пароль от хеша не значит что у американского NSA, китайского SSM или достаточно крупное предприятие это хоть немного задержит. А с другой стороны, даже ваш домашний SSH (или другой сервис) все эти уважаемые организации смогут брутфорсить со скоростью, в лучшем случае, тысячи попыток в секунду. И париться они над этим будут не одно столетие.
Мне, как пользователю, не принципиально как вы классифицируете инциденты безопасности. Мне важно чтобы мой пароль был недоступен в любом разумном сценарии - современные алгоритмы это обеспечивают.
Беда всех этих табличек со временем взлома - в том что с ними носятся безопасники или начальство которое не понимает банальных вещей:
подбор 8-символьного пароля через SSH (убираем все ограничители) или типичную веб-службу займет эдак лет 30000. Допускаю что поработав как следует вы оптимизируете на взлом за 3 столетия - не принципиально
поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вывод (мой): бессмысленно морочить голову пользователям требуя сложный и длинный пароль - делайте нормальный бекофис (например PBKDF2), не допускайте утечек, а если утекло - меняйте все пароли.
> Если бы хеши никогда не утекали, зачем бы они вообще были нужны?
Ну например для того чтобы админы/девелоперы (аппликации, базы данных, бекапа) тоже не имели простого доступа к паролям. Или вам кажется что обычный админ с его обычными ресурсами будет ждать 100 лет для взлома 8 символьного пароля из чистого любопытства ?
Поправьте меня, но никто хеши публично не выкладывает. Соответственно получение хешей и есть взлом. То что представлено в данной статье - это скорее расчет времени которое остается у компании для реакции на инцидент с кражей хешей.
В принципе вы - правы, а в частности интересно: были-ли предпосылки к успеху или это просто зондирование - попытка понять насколько все в индустрии "хорошо" или "не очень".
Не знаю как там где вы живете, но я знаю людей у которых снимались деньги с карточки (якобы за UberEats): было пару раз, но так как в конкретной стране UberEats-ом, да и конкретной карточкой, не пользовались - это позволило "заметить" эти пару десятков евро в общем потоке транзакций. Наиболее вероятно что в транспорте "прислонились". Банк все вернул без вопросов и карточку поменял. Сейчас в кошельке лежит RFID/NFC глушилка, а сама карточка в экранированном конверте.. ;-) - проблема исчезла, а до того раз в месяц-два "всплывало"
Можно спекулировать о бизнес моделе но феномен существует...
Согласен. И я таким баловался. Но вот вот случаев низкоуровневого чтения через прямое программирование контролера я могу припомнить единицы: помниться был любопытный вариант защиты где дискета не портилась но защитные метки писались (и читались) в меж-секторном пространстве..
Насколько я помню, программы которые навешивали защиту - таким баловались (типично чтобы нестандартно отформатировать дискету), а вот то, что шло в продажу обходилось стандартными прерываниями (иначе не везде-бы работало...)
Защита через дискеты с дефектами - так себе: с одной стороны лицензионный продут довольно скоро становился нерабочим - дискеты не долговечны, а с другой - защита полезной программы относительно легко ломается (и напрямую и через свой обработчика на int13h)
Подозреваю что ваш 5570 шел с блоком питания на 130W - это больше 100W которые может выдать PD3. И как я нашел в интернете: " Dell did something proprietary on some of their other docks and systems to support running up to 130W over a single USB-C/TB3 connector" - для нормальной работы надо дождаться чтобы Dell это захотел...
Подозреваю что проблема в кабеле или самом ноутбуке: технически может но не хочет рисковать...
Мой Latitude 7390 работает без проблем с UGREEN Nexode 200W, а Latitude 7530 (родной блок на 160W) включается но тоже как-то странно: пока не разбирался.
Плюсую. Я к нему еще взял UGREEN Nexode 200W - оптимально в дороге: хватает и для работы и для зарядки - можно с собой кучу зарядников в путешествиях не возить.
А зачем? Десятилетиями основным преимуществом Китая была недорогая рабочая сила, а основной претензией к Китаю - практически узаконенное воровство технологий и ноу-хау. IMHO Это никаким боком неинтересно ASML.
По "блекаутам" вы ошибаетесь. В гипотетическом случае нехватки мощностей (по любой причине) - отключают "неприоритетных" потребителей (есть специальный контракт (в том числе для обывателей) на поставку электроэнергии где вы платите дешевле рынка но соглашаетесь что несколько десятков дней в году у вас могут быть перебои).
Я живу в Европе и все проблемы с электроэнергией за последние десятилетия у меня дома, на работе, у знакомых, по новостям - банальны: головотяпство (на работе : экскаватор рубанул основной и один из резервных кабелей, а третья линия была на обслуживании), природа (ураганы/бури свалили деревья которые порвали воздушные линии), ошибки планирования (высоковольтную линию отключили и отсоединили для проводки крупного корабля, а операция затянулась - попали под вечерний пик потребления без достаточный линий для компенсации поставками из соседних регионов), и т.п.
Разного порядка риски: одно дело подсказать подружке пароль ее начальницы (и поди докажи откуда она его узнала), а другое - апдетить запись. Во первых не факт что обычный админ/девелопер сможет обновить хаш (при правильном дизайне - не сможет). Во вторых апдейт оставит всякие прямые и косвенные следы (время обновления, логи, бекапы, и т.д.)
Ключевой момент моей фразы " древнему ". Собственно вся статья об этом. MD5 - мгновенно, bcrypt - чуть дольше.
Собственно есть целая палитра взломщиков и способов. На одном конце спектра есть обычный человек как вы - вы на вашем компьютере ничего особого сделать не сможете (кроме MD5 или совсем коротких паролей завернутых в bcrypt). На другом есть заинтересованные люди побогаче (разведки крупных стран) которые активно эксплуатируют чужие утечки. Между ними целая палитра возможностей.
Это все правда, но не вся правда: соль просто сильно увеличивает стоимость взлома.
При утечке утечет и хеш и соль: взломщик может практически до бесконечно распаралеливать поиск колизии. Просто, для примера, посмотрите в статье скорость поиска для bcrypt (он использует соль).
Я застал ту эпоху.
1) Основное: не допустить чтобы амин/девелопер мог по быстрому подсмотреть чужой пароль да и поправить чтонибуть себе или попросившей его подружке.
2) Убрать проблему "неприличных" паролей которые могли ранить тонкую психику админов. Было и такое :-)
И поначалу (до появления NVidia с CUDAой) коллизию реально трудно было найти - давным давно - это действительно защищало...
Вы фундаментально ошибаетесь допуская принятие утечки как данность:
Хороших алгоритмов для хеширования единицы. Криптография - сложная наука и при попытке изобрести свой велосипед вы точно будете в зоне риска. А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее.
Скорость поиска коллизии можно увеличивать практически до бесконечности (распараллеливать на все доступные ресурсы, специализирование ASICи, и.т.д.) да к тому-же все это можно делать незаметно для жертвы.
Не ленитесь: сегодня утечка хешей практичеки такая-же катастрофа как утечка паролей в чистом виде. Тот что лично вы не можете подобрать пароль от хеша не значит что у американского NSA, китайского SSM или достаточно крупное предприятие это хоть немного задержит. А с другой стороны, даже ваш домашний SSH (или другой сервис) все эти уважаемые организации смогут брутфорсить со скоростью, в лучшем случае, тысячи попыток в секунду. И париться они над этим будут не одно столетие.
Мне, как пользователю, не принципиально как вы классифицируете инциденты безопасности. Мне важно чтобы мой пароль был недоступен в любом разумном сценарии - современные алгоритмы это обеспечивают.
Беда всех этих табличек со временем взлома - в том что с ними носятся безопасники или начальство которое не понимает банальных вещей:
подбор 8-символьного пароля через SSH (убираем все ограничители) или типичную веб-службу займет эдак лет 30000. Допускаю что поработав как следует вы оптимизируете на взлом за 3 столетия - не принципиально
поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вывод (мой): бессмысленно морочить голову пользователям требуя сложный и длинный пароль - делайте нормальный бекофис (например PBKDF2), не допускайте утечек, а если утекло - меняйте все пароли.
> Если бы хеши никогда не утекали, зачем бы они вообще были нужны?
Ну например для того чтобы админы/девелоперы (аппликации, базы данных, бекапа) тоже не имели простого доступа к паролям. Или вам кажется что обычный админ с его обычными ресурсами будет ждать 100 лет для взлома 8 символьного пароля из чистого любопытства ?
Поправьте меня, но никто хеши публично не выкладывает. Соответственно получение хешей и есть взлом. То что представлено в данной статье - это скорее расчет времени которое остается у компании для реакции на инцидент с кражей хешей.
В принципе вы - правы, а в частности интересно: были-ли предпосылки к успеху или это просто зондирование - попытка понять насколько все в индустрии "хорошо" или "не очень".
Не знаю как там где вы живете, но я знаю людей у которых снимались деньги с карточки (якобы за UberEats): было пару раз, но так как в конкретной стране UberEats-ом, да и конкретной карточкой, не пользовались - это позволило "заметить" эти пару десятков евро в общем потоке транзакций. Наиболее вероятно что в транспорте "прислонились". Банк все вернул без вопросов и карточку поменял. Сейчас в кошельке лежит RFID/NFC глушилка, а сама карточка в экранированном конверте.. ;-) - проблема исчезла, а до того раз в месяц-два "всплывало"
Можно спекулировать о бизнес моделе но феномен существует...
Согласен. И я таким баловался. Но вот вот случаев низкоуровневого чтения через прямое программирование контролера я могу припомнить единицы: помниться был любопытный вариант защиты где дискета не портилась но защитные метки писались (и читались) в меж-секторном пространстве..
Насколько я помню, программы которые навешивали защиту - таким баловались (типично чтобы нестандартно отформатировать дискету), а вот то, что шло в продажу обходилось стандартными прерываниями (иначе не везде-бы работало...)
Защита через дискеты с дефектами - так себе: с одной стороны лицензионный продут довольно скоро становился нерабочим - дискеты не долговечны, а с другой - защита полезной программы относительно легко ломается (и напрямую и через свой обработчика на int13h)
IMHO Фото вашего "Datasette " - магнитофон к Commodore 64. С64 шел с таким кассетником или с дисководом (в более жирной конфигурации)
Подозреваю что ваш 5570 шел с блоком питания на 130W - это больше 100W которые может выдать PD3. И как я нашел в интернете: " Dell did something proprietary on some of their other docks and systems to support running up to 130W over a single USB-C/TB3 connector" - для нормальной работы надо дождаться чтобы Dell это захотел...
Подозреваю что проблема в кабеле или самом ноутбуке: технически может но не хочет рисковать...
Мой Latitude 7390 работает без проблем с UGREEN Nexode 200W, а Latitude 7530 (родной блок на 160W) включается но тоже как-то странно: пока не разбирался.
Плюсую. Я к нему еще взял UGREEN Nexode 200W - оптимально в дороге: хватает и для работы и для зарядки - можно с собой кучу зарядников в путешествиях не возить.
А зачем? Десятилетиями основным преимуществом Китая была недорогая рабочая сила, а основной претензией к Китаю - практически узаконенное воровство технологий и ноу-хау. IMHO Это никаким боком неинтересно ASML.
По "блекаутам" вы ошибаетесь. В гипотетическом случае нехватки мощностей (по любой причине) - отключают "неприоритетных" потребителей (есть специальный контракт (в том числе для обывателей) на поставку электроэнергии где вы платите дешевле рынка но соглашаетесь что несколько десятков дней в году у вас могут быть перебои).
Я живу в Европе и все проблемы с электроэнергией за последние десятилетия у меня дома, на работе, у знакомых, по новостям - банальны: головотяпство (на работе : экскаватор рубанул основной и один из резервных кабелей, а третья линия была на обслуживании), природа (ураганы/бури свалили деревья которые порвали воздушные линии), ошибки планирования (высоковольтную линию отключили и отсоединили для проводки крупного корабля, а операция затянулась - попали под вечерний пик потребления без достаточный линий для компенсации поставками из соседних регионов), и т.п.
А насколько вы сами оцениваете свою "продуктивность" в режиме путешествий (смена мест, проблемы связи, недосып, и т.п.) по сравнению с домом ?