Господа, извиняюсь, если кого-то запутал своим комментарием. Я действительно рассматривал конкретную реализацию py-bcrypt, которая среди прочих реализаций порождает ложную идею, что «соль является результатом вычисления сложной функции».
Поскольку соль обязательна для Blowfish, многие реализации BCrypt (py-bcrypt, JFBCrypt (objective c), jBCrypt (java), bcrypt.net) предлагают собственную функцию типа gensalt для генерации соли, зависящей от сложности (на самом деле не очень зависящей). Но везде gensalt нужно вызвать самому, кроме bcrypt-ruby, где вообще момент генерации соли скрыт.
Остаётся реализация на PHP, которой нет. Но если есть поддержка BlowFish, BCrypt достаточно просто реализовать самому. Только если отклониться от формата $Version$LogRounds$base64(SaltHash), ни одна библиотека не сможет работать с ним. Тут заканчивается алгоритм и начинается реализация.
def gensalt(log_rounds = 12):
"""Generate a random text salt for use with hashpw(). "log_rounds"
defines the complexity of the hashing, increasing the cost as
2**log_rounds."""
return encode_salt(os.urandom(16), min(max(log_rounds, 4), 31))
Где encode_salt просто переводит псевдослучайную последовательность 16 байтов в base64 и возвращает строку вида $2$log_rounds$base64(salt). Ничего сложного тут нет.
Тоже нет. Выходом BCrypt является длинная строка вида $A$BB$SaltCyphertext, где A — версия алгоритма (2), BB — log2 от количества раундов шифрования Blowfish, а Salt и Cypertext — двоичная соль и двоичный хэш в представлении base64.
Скорее всего это историческое прошлое конкретных продуктов. Конкретный пример: в MediaWiki используется два вида хэшей: «:A:md5(password)» и «:B:salt-md5(salt-md5(password))». Первый вариант — исторический, когда ещё радужные таблицы не были в обиходе. Потом до разработчики сообразили, что нужна соль, но что делать сайтам, где уже зарегистрированы тысячи пользователей, а в базе данных только хэши? Пришлось хэшировать хэши.
Да, можно сказать, если у вас в профиле «Microsoft Student Partner» и все ваши познания о линуксе сформированы путём обобщения политики Microsoft на другие компании (что подтверждается вашим комментарием выше о различиях пар коммерческих/некоммерческих дистрибутивов).
Ализар, на хабре итак уже 76 проплаченных аккаунта, которые каждый день заваливают хабр рекламой о ещё невышедших продуктах в обход adv@thematicmedia.ru. Теперь и сотрудники «Тематические Медиа» занимаются переводом и размещением чужой рекламы. Сколько можно? Скоро вместо хабра останется «Ехал Windows через Windows Enterprise в два раза быстрее бета-версия».
Вообще прекрасно. Теперь firefox кэширует яндекс в localStorage, так что даже если прописать Google в about:config, на домашней странице будет использоваться яндекс. В связи с этим только что обновил расширение. Желающие пока могут поставить версию 0.0.2 с addons.mozilla.org/ru/firefox/addon/reset-search-preferences/versions/, пока версия не пройдёт предварительную проверку.
Обратимое преобразование регистров невозможно ни с одной кодировкой. Так получается, например, из-за сигмы Σ, которая является заглавным представлением одновременно для ς и σ. И обратный пример — эсцет ß в верхнем регистре по правилам немецкого языка внезапно превращается в SS (несмотря на существование ẞ).
Выше уже предупредили об неточности в строке «Windows строки должны быть в Юникоде». По-моему стоит исправить статью, чтобы не распространялось.
А вообще к выбору кодировки стоит подходить осторожно. Никаких проблем в линуксе, utf-8 обеспечит работу программы с чем угодно. Проблемы начнутся, когда вы захотите применить utf-8 к сломанной кодировке utf-16 в представлении windows. Дело в том, что локализованные версии windows периодически мешают кодировки в именах файлов. В результате получаются пути вида www.graphicall.org/ftp/ideasman42/bad_utf8.txt (кодировка utf-8, открывать в редакторе типа SciTE, которые умеют работать с битыми кодировками). Я эту блядскую строку даже не могу на хабр добавить, поскольку здравомыслящие браузеры при копировании и вставке меняют битый символ на символ подстановки �. На самом деле за этим символом в данное случае скрывается символ с кодом 0xE9 (é) из однобайтовой кодировки Windows-1252. Такие строки нельзя преобразовать обратно в utf-16 так, чтобы получилась исходная битая строка. В связи с этим, с подобными файлами не смогут работать все программы в линуксе, а также программы, написанные по статье.
Пикрелейтед. На нём всё, начиная с файлов за последние 5 лет, заканчивая убунтой. Так что мой вариант скорее «Могу достучаться до любой рабочей машины в любое время без всякого интернета».
Оценку не ставил, но лично мне кажется избыточным столь подробное описание процесса кликов по галочкам и вбивания ключевых слов в нужные поля. Если бы речь шла хотя бы о написании какого-то конфига с регулярными выражениями — это ещё куда ни шло. Но тут всё настолько просто, что любой человек, знающий синтаксис языка, справится без всякого туториала.
+1 к XeLaTeX. Когда с ним работаешь, можно забыть, что существуют другие кодировки, кроме юникода. В частности, такие мелочи, как выделение и копирование текста из сгенерированного pdf.
Ещё очень удобно работать с системными ttf-шрифтами (без конвертации), поскольку стандартные семейства в latex достаточно сильно отличаются от привычных ttf-аналогов.
Поскольку соль обязательна для Blowfish, многие реализации BCrypt (py-bcrypt, JFBCrypt (objective c), jBCrypt (java), bcrypt.net) предлагают собственную функцию типа gensalt для генерации соли, зависящей от сложности (на самом деле не очень зависящей). Но везде gensalt нужно вызвать самому, кроме bcrypt-ruby, где вообще момент генерации соли скрыт.
Остаётся реализация на PHP, которой нет. Но если есть поддержка BlowFish, BCrypt достаточно просто реализовать самому. Только если отклониться от формата $Version$LogRounds$base64(SaltHash), ни одна библиотека не сможет работать с ним. Тут заканчивается алгоритм и начинается реализация.
Где encode_salt просто переводит псевдослучайную последовательность 16 байтов в base64 и возвращает строку вида $2$log_rounds$base64(salt). Ничего сложного тут нет.
Нет.
Тоже нет. Выходом BCrypt является длинная строка вида $A$BB$SaltCyphertext, где A — версия алгоритма (2), BB — log2 от количества раундов шифрования Blowfish, а Salt и Cypertext — двоичная соль и двоичный хэш в представлении base64.
А брутфорсить такие хэши (и то только такие) умеет John the Ripper community-enhanced version.
https://addons.mozilla.org/ru/firefox/addon/reset-search-preferences/
Я давно не проверял работоспособность этого расширения, т. к. из репозитария ubuntu приходит версия с гуглом, но должно работать.
А вообще к выбору кодировки стоит подходить осторожно. Никаких проблем в линуксе, utf-8 обеспечит работу программы с чем угодно. Проблемы начнутся, когда вы захотите применить utf-8 к сломанной кодировке utf-16 в представлении windows. Дело в том, что локализованные версии windows периодически мешают кодировки в именах файлов. В результате получаются пути вида www.graphicall.org/ftp/ideasman42/bad_utf8.txt (кодировка utf-8, открывать в редакторе типа SciTE, которые умеют работать с битыми кодировками). Я эту блядскую строку даже не могу на хабр добавить, поскольку здравомыслящие браузеры при копировании и вставке меняют битый символ на символ подстановки �. На самом деле за этим символом в данное случае скрывается символ с кодом 0xE9 (é) из однобайтовой кодировки Windows-1252. Такие строки нельзя преобразовать обратно в utf-16 так, чтобы получилась исходная битая строка. В связи с этим, с подобными файлами не смогут работать все программы в линуксе, а также программы, написанные по статье.
Пикрелейтед. На нём всё, начиная с файлов за последние 5 лет, заканчивая убунтой. Так что мой вариант скорее «Могу достучаться до любой рабочей машины в любое время без всякого интернета».
Ещё очень удобно работать с системными ttf-шрифтами (без конвертации), поскольку стандартные семейства в latex достаточно сильно отличаются от привычных ttf-аналогов.