"Нуль-блоками" я называю блоки (части файла), заполненные нулевыми байтами. Можно заранее посчитать их хеши и не запрашивать эти блоки у источников, а сразу помечать их уже загруженными.

Нуль-блоки не надо хранить на диске. Благодаря sparse флагу, операционная система просто помечает этот участок файла как заполненный нулями и не хранит эти нули на диске.

Также, показывая что участки скачиваемого файла заполнены нулями, можно мотивировать пользователя отказаться от скачивания и распространения битого файла. В моей версии Shareaza эти участки помечаются красной полосой сверху на полосе прогресса загрузки файла.

Откуда берутся нуль-блоки в файле

1. Раздающий не дождался полного скачивания и проверки файла и выложил неполный(partial) файл.
2. Результат повреждения сектора диска раздающего.

Это те варианты, которые пришли в голову.

Почему эти файлы продолжают распространяться

1. Видео/аудио файл может иметь нуль-блок в середине и спокойно воспроизводится, просто перескакивая то место, где попался нуль-блок. Тем самым он может казаться целым.
2. Образ диска также может иметь нуль-блоки в разных местах и это проявит себя только при попытке чтения файлов из этих блоков.

Осторожно: данный пост может вызывать непродолжительное обострение паранойи

Привет! Не верите ли вы в популярные продукты для защищённой переписки так, как не верю в них я? Например, в браузерные крипточаты с шифрованием на стороне клиента, или в p2p-криптомессенжеры?

В данном посте речь пойдет об организации защищённого общения между двумя собеседниками. Он адресован таким же недоверчивым людям как я, поэтому в нём не будет ни кода, написанного мной, ни изобретённых на коленке протоколов и алгоритмов. Будет использоваться только библиотека openssl и набор программ openssh.

На одной из популярных торговых площадок «теневого интернета» The Real Deal появилось предложение о продаже 167 миллионов пользовательских аккаунтов социальной сети LinkedIn. Из них 117 миллионов имеют хэшированные пароли, которые, тем не менее, не слишком сложно взломать. В последний раз, когда LinkedIn обнародовала информацию о своей работе, она сообщала, что всего в базе зарегистрировано 433 миллиона пользователей.

База содержит идентификатор пользователя, email и хэш пароля. Хакер просит за эту базу всего 5 BTC (порядка $2270) и обещает подтвердить подлинность, поискав по запросу в базе нужный e-mail.

Специалисты по безопасности, изучающие базу, подтверждают её подлинность, и указывают, что эта информация утекла с сайта LinkedIn в 2012 году. Тогдашняя громадная утечка привела к появлению в общем доступе 6,5 миллионов учётных записей. Однако тогда социальная сеть не подтвердила утечку, не сообщила, сколько пользователей она затронула, упорно хранила молчание, в связи с чем эту историю успешно забыли.

В это трудно поверить, но около 30% сайтов держат пароли своих пользователей в незащищённом виде. Если кто-то проникнет к ним в систему, то все пароли будут перед ними открытым текстом.

Продвинутым пользователям должно быть обидно, если они генерируют и запоминают 15-символьные пароли, которые так хранятся.

Добрый день Хабра-сообщество!
Столкнулся я с системой платежей liqpay. В принципе, система создает очень приятное первое впечатление.
Но при попытке её интеграции на сайт я столкнулся с несколькими недостатками и проблемами.
Их описанием и решением я хотел бы с вами поделиться.

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

На этой неделе три самых интересных новости о безопасности не имеют между собой ничего общего, кроме толстого слоя подтекстов. Если не заниматься темой постоянно, важность некоторых событий можно оценить неправильно, или не увидеть какие-то важные детали. Попробую, по мере сил, объяснить на примерах, хотя подтексты — штука такая — каждому видится что-то свое. Добро пожаловать в 11 эпизод сериала Security Week им. Срыва Покровов. Традиционные правила: каждую неделю редакция новостного сайта Threatpost выбирает три наиболее значимых новости, к которым я добавляю расширенный и беспощадный комментарий. Все эпизоды сериала можно найти тут.

В далекие времена, до фейсбука и гугла, когда 32 мегабайта RAM было дофига как много, security была тоже… немножко наивной. Вирусы выдвигали лоток CD-ROM-а и играли Янки Дудль. Статья «Smashing the stack for fun and profit» уже была задумана, но еще не написана. Все пользовались telnet и ftp, и только особо продвинутые параноики знали про ssh.

Вот примерно в это время, плюс-минус год, родился MySQL и были в нем юзеры, которых надо было не пускать к чужим данным, но пускать к своим.

Michael Widenius (или просто Monty) явно был знаком с параноидальными безопасниками не понаслышке, чего стоит один такой момент (из исходников, global.h):

/* Paranoid settings. Define I_AM_PARANOID if you are paranoid */
#ifdef I_AM_PARANOID
#define DONT_ALLOW_USER_CHANGE 1
#define DONT_USE_MYSQL_PWD 1
#endif

Так что неудивительно, что пароли в MySQL открытым текстом не передавались никогда. Передавались случайные строки на основе хешей. А конкретно, первый протокол аутентификации (цитируется по mysql-3.20, 1996) работал так:

На данный момент хэш можно вскрыть пятью способами: грубый перебор (брутфорс), подбор по словарю, по словарю с правилами (гибридная атака), rainbow таблицы (радужные таблицы) и криптоатака. Сами хэши можно разделить на обычные хэши, и хэши с солью (salt, «затравка»). Эта статья посвящена программам john и mdcrack. На их примере, также рассмотрим основные методы для реализации брутфорса.

Добрые люди выложили в открытый доступ базу паролей MySpace, которая некоторое время ходила по подпольным форумам и продавалась за большие деньги. Теперь она бесплатна и открыта для всех.

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

Myspace.com.rar (14,2 ГБ)
Пароль на RAR-архив: KLub8pT&iU$8oBY(*$NOiu

Скачать

SHA1: 8C7E FFE4 3486 C617 E1B4 E295 DBF7 9E10 01AC 86BD
SHA256: 5FA0 5F95 1EFD DA18 8A2E 3D50 8948 1A4F AACA 311E C559 205F EB15 B2BB F7DE EC61

Торрент
magnet:?xt=urn:btih:17E6FC94DAE0A3168301012C290A53A2BD314A28

В Сети появился оригинальный сервис Norbt (No robot), который позволяет любому желающему создать за пару секунд свою собственную страничку с зашифрованным текстом. Увидеть содержимое страницы можно только зная пароль.

Создатели веб-приложения утверждают, что здесь используется стойкая криптография, так что даже в случае взлома сервера хакер не сможет расшифровать текст. Данные на сервере хранятся в таком виде:

Answer: SHA1(answer + salt1), salt1
Text: AES128(SHA1(answer + salt2), IV, Mode.CFB, text), salt2, IV

То есть чтобы расшифровать текст, хакеру придётся взломать или SHA1(answer + salt1), или AES128.

Прослушивание трафика путём взлома SSL тоже не поможет хакеру, потому что все операции шифрования выполняются в браузере.

Вчера я наконец-то выпустил первую публичную версию Lamer News, это одновременно и реальный пример использования Redis в виде сайта напободие Hacker News, и проект совершенно независимого сайта про новости из мира программирования.

Проект был хорошо принят сообществом, и был в топе HN в течение некоторого времени. Спасибо за обратную связь.

После релиза я получил несколько просьб об изменении хэш-функции, которую я использовал для того, чтобы хэшировать пароли в БД:

# Turn the password into an hashed one, using
# SHA1(salt|password).
def hash_password(password)
    Digest::SHA1.hexdigest(PasswordSalt+password)
end

Этот код использует SHA1 с солью. Как отметили читатели, это не самый безопасный выбор, поскольку есть способы вычислить SHA1 очень быстро. Через некоторое время люди хором начали твитить и писать в комментах одно и то же предложение: «используй BCrypt». Я предложил использовать вложенные SHA1 в цикле, чтобы избежать добавления новых зависимостей в коде (если вы проверите README, одной из целей является сделать код простым и с как можно меньшим количеством зависимостей). И тут это случилось: догма шифрования. Никаких рассуждений о криптопримитивах и их возможных применениях и комбинациях, просто тупо «используй BCrypt». В глазах этих товарищей программисты — просто тупые дроны, исполняющие гайдлайны, которые не могут ни в коем случае рассуждать о криптографии. Но об этом позже…

Давайте пока сделаем шаг назад и рассмотрим исходную проблему со всем этим, и насколько небезопасен этот код.

В сети очень много сайтов для подсчета хэшей (MD5, SHA1, SHA2) файлов, однако, все сервисы, что я смог найти, имеют один и тот же недостаток: размер файла ограничен. Также необходимо сначала загрузить файл на сервер, чтобы получить результат вычислений. Это очень неудобно.

Поэтому я решил создать небольшой сервис MD5 File, расчет в котором будет происходить непосредственно в браузере пользователя. Нет необходимости загружать файлы на сервер (экономим трафик и время) и появляется возможность работать с файлами любого размера.

Картинка и немного информации под катом

Секреты создания CSP для Windows раскрыты в статье Ю.С.Зырянова.

Российские криптоалгоритмы ГОСТ реализованы в OpenSSL Gost.

Удивлен, что на просторах Интернета не удалось найти подтверждения, что кем-то был создан интерфейс криптопровайдера ГОСТ под Windows с использованием вышеприведенных инструментов.

Можно подумать, что эта задача под силу только крупным коммерческим компаниям, имеющим большой опыт в сфере информационной безопасности, к примеру, таким как:

• ООО «Лисси»
• ОАО «ИнфоТеКС»
  
• ЗАО «Сигнал-КОМ»
  
• ОКБ САПР
  
• ну и конечно, ООО «КРИПТО-ПРО»
  

Опровергнуть, хотя бы частично, это утверждение и будет задачей данной статьи.

Неделю назад утекла база хешей с LinkedIn, для других это событие может быть примечательным само по себе, но для меня, в первую очередь, это означает возможность провести анализ современных возможностей взлома паролей. И я не собираюсь рассказывать о том сколько раз слово «password» было встречено среди паролей и о том, сколько времени занимает перебор шестисимвольных комбинаций. Скорее буду пугать пользователей тем, насколько сложные пароли можно «взломать» за несколько часов. А программистам расскажу как это возможно эффективно реализовать, и в качестве небольшого подарка приложу программу, которую я написал для массового аудита. Присутствует и некоторый ликбез по использованию радужных таблиц с простыми выводами.

И так, за час удалось «восстановить» около 2.5 миллионов паролей на средней рабочей конфигурации, без специальных словарей и радужных таблиц. Среди найденных паролей присутствуют 16-символьные алфавитно-цифровые комбинации, и далеко не в единственном экземпляре.

Когда на хабре был опубликован пост о том, что компания Stripe проводит конкурс Capture the Flag, я незамедлительно зарегистрировался как участник.

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

Уровни с 0-го по 6-й не представляли особого труда — стандартные SQL- и JavaScript-инъекции, загрузка на сервер PHP-скрипта вместо картинки и т.п.

А вот 7-й уровень заставить меня поломать голову…

Предыстория

Не так давно, а именно 5 июня хабрачеловек по имени alan008 задал вопрос. Чтобы не заставлять ходить за подробностями, приведу его здесь:

Нужна помощь!

За несколько лет с разных трекеров (преимущественно c rutracker'а) разными клиентами (преимущественно uTorrent'ом) скачано много гигабайт разного полезного контента. Скачанные файлы впоследствии вручную перемещались с одного диска на другой, uTorrent их соответственно не видит. Многие .torrent файлы устарели сами по себе (например, велась раздача сериала путем добавления новых серий заменой .torrent файла).

Теперь сам вопрос: есть ли способ автоматически (не вручную) установить соответствие между имеющимися на компьютере .torrent файлами и содержимым, раскиданным по разным логическим дискам компьютера? Цель: удалить лишние (неактуальные) .torrent файлы, а для актуальных — поставить всё на раздачу. У кого какие идеи? :)

При необходимости (если это требуется) можно снова поместить все файлы данных в один каталог на одном логическом диске.

В обсуждениях сошлись на том, что если это и можно сделать, то только ручками. Мне же этот вопрос показался интересным, и после возвращения из отпуска я нашел время, чтобы в нем разобраться.

Потратив в общей сложности неделю на разбор формата .torrent-файла, поиск нормально работающей библиотеки для его парсинга, я приступил к написанию программы, которая позволит решить проблему затронутую в упомянутом вопросе.

Прежде чем начать, стоит отметить несколько моментов:

1. Получилось много, но не все.
2. По формату файла .torrent будут даны лишь необходимые пояснения.
3. Людей, чувствительных к временами некачественному коду, прошу меня заранее простить — я знаю, что многое можно было написать лучше, оптимальнее и безглючнее.

Для тех, кому интересно, что из этого получилось, технические подробности и подводные камни — прошу под кат.