Логика работы сборщика мусора — загадка и нигде не описана. По одним только данным тестов очень сложно сделать reverse engineering. Я думаю, что кроме паттерна «случайная запись блоками по 4 КБ и QD 32» есть и другие, более популярные паттерны, и сборщик мусора больше ориентируется на них. Также, согласен с комментарием выше.
Без команды TRIM диск никогда не узнает, что страница освободилась, и сборщик мусора будет бесконечно её копировать. У Plextor M5M на борту 256 ГБ двоичных, пользователю доступны 256 ГБ десятичных, соответственно размер резервной области примерно 6,87%. Это очень мало для высокой скорости записи: полностью заполненный диск даёт максимум 6000 IOPS, если сделать 25% over-provisioning, то получим 25000 IOPS.
Я уже упоминал SRP. SCRAM — это более простой и наглядный алгоритм, который может защитить процесс авторизации от прослушивания канала. Если есть ещё алгоритмы с такими же свойствами, которые ещё не упоминались, то напишите.
Улучшим. DK рассчитывается как и ранее, но в БД сохраняем хеш от него: на сервере храним "PBKDF2-HMAC-SHA512":"1000":salt:H(DK).
1) Клиент передаёт на сервер: логин.
2) Сервер передаёт клиенту: случайный session_id, salt, 1000 — из БД.
3) Клиент рассчитывает DK и HMAC и передаёт серверу XOR этих двух значений: response = HMAC(H(DK), session-id) XOR DK.
4) Сервер также рассчитывает HMAC и делает XOR с ответом клиента, чтобы восстановить DK': DK' = HMAC(H(DK), session-id) XOR response, при этом H(DK) сервер берёт из БД. Дальше сервер рассчитывает H(DK') и сравнивает со значением в БД.
Так мы получим нужные нам свойства: компрометация БД не позволит залогиниться на сайте или узнать пароль, пароль не передаётся по сети, один и тот же ответ клиента нельзя использовать дважды для логина.
Также в этот алгоритм можно добавить не только авторизацию клиента, но и авторизацию сервера: клиент убеждается, что сервер знает какой-то секрет, хранимый в БД. Подробнее такая реализация описана в RFC 5802: SCRAM.
Слабое место алгоритма: если скомпрометирована БД, и при этом подслушан трафик настоящего клиента, то можно восстановить DK, а значит и авторизоваться как этот клиент. Но это будет работать только для этого конкретного сайта. Ещё одна угроза: если злоумышленник подслушает трафик, он может начать offline brute force атаку с целью поиска пароля, но от этого защищают только упоминавшиеся ранее алгоритмы SRP или EKE.
Попробуем собрать полную схему из криптографических примитивов.
Существует стандартная схема PBKDF2, которой на вход передаётся пароль, соль и число итераций, на выходе получаем хеш много раз от пароля с солью. Используем DK = PBKDF2(HMAC−SHA512, passphrase, salt, 1000 /* число итераций */, 512 /* длина результата */), при регистрации пользователя в БД сохраняем строку PBKDF2-HMAC-SHA512:1000:salt:DK.
При логине клиенту передаём строку из БД, кроме самого хеша: PBKDF2-HMAC-SHA512:1000:salt. Клиент рассчитывает DK, зная алгоритм, число итераций, соль, и пароль, введённый пользователем. Полученное значение уже можно передавать на сервер и сравнивать с БД, но тогда любой, кто сможет один раз подслушать канал связи, сможет авторизоваться любое число раз.
Поэтому пусть сервер сначала придумает случайный session_id, запомнит его и передаст клиенту: session_id и PBKDF2-HMAC-SHA512:1000:salt. Клиент не будет передавать DK, а рассчитает HMAC-SHA512(DK, session_id) и передаст результат. Сервер рассчитает ту же самую функцию и сравнит с данными, полученными от клиента.
Для аутентификации теоретически не нужно передавать пароль, достаточно дать знать, что и сервер и клиент знают один и тот же пароль, канал передачи данных не получает никакой информации о пароле. Для этого существуют протоколы Zero-knowledge password proof: Secure Remote Password protocol (внизу практические реализации) и Encrypted key exchange.
Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает HMAC от пароля (ключ k) и полученного числа (сообщение m), сервер рассчитывает то же самое от известного пароля и сверяет с полученным от браузера.
По сети ходит только хеш, каждый раз новый, и два раза один и тот же хеш не подходит (защита от replay attack), активный атакующий также не сможет собрать достаточно информации, поскольку, зная много пар (m, t), невозможно вычислить ключ k, удовлетворяющий условию HMAC(k, m) = t.
FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.
1. Спасибо, исправил.
2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
3. Верно, исправил.
4. Вообще, да, но ECDHE считается более производительным, чем DHE.
За аргументами ходить далеко не надо. Очень часто, когда программист говорит, что он лучше знает, и реализовывает криптографию самостоятельно, находятся ошибки. Даже у экспертов.
Например, автор scrypt недавно ошибся в реализации AES-CTR и поставил под серьёзную угрозу безопасность чужих данных.
Улучшим.
DKрассчитывается как и ранее, но в БД сохраняем хеш от него: на сервере храним"PBKDF2-HMAC-SHA512":"1000":salt:H(DK).1) Клиент передаёт на сервер: логин.
2) Сервер передаёт клиенту: случайный
session_id,salt,1000— из БД.3) Клиент рассчитывает
DKиHMACи передаёт серверуXORэтих двух значений:response = HMAC(H(DK), session-id) XOR DK.4) Сервер также рассчитывает
HMACи делаетXORс ответом клиента, чтобы восстановитьDK':DK' = HMAC(H(DK), session-id) XOR response, при этомH(DK)сервер берёт из БД. Дальше сервер рассчитываетH(DK')и сравнивает со значением в БД.Так мы получим нужные нам свойства: компрометация БД не позволит залогиниться на сайте или узнать пароль, пароль не передаётся по сети, один и тот же ответ клиента нельзя использовать дважды для логина.
Также в этот алгоритм можно добавить не только авторизацию клиента, но и авторизацию сервера: клиент убеждается, что сервер знает какой-то секрет, хранимый в БД. Подробнее такая реализация описана в RFC 5802: SCRAM.
Слабое место алгоритма: если скомпрометирована БД, и при этом подслушан трафик настоящего клиента, то можно восстановить DK, а значит и авторизоваться как этот клиент. Но это будет работать только для этого конкретного сайта. Ещё одна угроза: если злоумышленник подслушает трафик, он может начать offline brute force атаку с целью поиска пароля, но от этого защищают только упоминавшиеся ранее алгоритмы SRP или EKE.
Существует стандартная схема
PBKDF2, которой на вход передаётся пароль, соль и число итераций, на выходе получаем хеш много раз от пароля с солью. ИспользуемDK = PBKDF2(HMAC−SHA512, passphrase, salt, 1000 /* число итераций */, 512 /* длина результата */), при регистрации пользователя в БД сохраняем строкуPBKDF2-HMAC-SHA512:1000:salt:DK.При логине клиенту передаём строку из БД, кроме самого хеша:
PBKDF2-HMAC-SHA512:1000:salt. Клиент рассчитываетDK, зная алгоритм, число итераций, соль, и пароль, введённый пользователем. Полученное значение уже можно передавать на сервер и сравнивать с БД, но тогда любой, кто сможет один раз подслушать канал связи, сможет авторизоваться любое число раз.Поэтому пусть сервер сначала придумает случайный
session_id, запомнит его и передаст клиенту:session_idиPBKDF2-HMAC-SHA512:1000:salt. Клиент не будет передаватьDK, а рассчитаетHMAC-SHA512(DK, session_id)и передаст результат. Сервер рассчитает ту же самую функцию и сравнит с данными, полученными от клиента.Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает
HMACот пароля (ключk) и полученного числа (сообщениеm), сервер рассчитывает то же самое от известного пароля и сверяет с полученным от браузера.По сети ходит только хеш, каждый раз новый, и два раза один и тот же хеш не подходит (защита от replay attack), активный атакующий также не сможет собрать достаточно информации, поскольку, зная много пар
(m, t), невозможно вычислить ключk, удовлетворяющий условиюHMAC(k, m) = t.2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
3. Верно, исправил.
4. Вообще, да, но ECDHE считается более производительным, чем DHE.
Использую в Windows для Firefox, Thundebrird, Skype и Emacs.
— bcrypt,
— PBKDF2 с HMAC-SHA256 (рекомендовано NIST в SP 800-132),
— scrypt.
Рекомендованная длина хеша.
Множественное хеширование слегка замедляет подбор пароля, но и снижает криптографическую стойкость (сужает выходное множество значений).
Например, автор scrypt недавно ошибся в реализации AES-CTR и поставил под серьёзную угрозу безопасность чужих данных.
Используйте:
Рекомендованная длина хеша.
Множественное хеширование слегка замедляет подбор пароля, но и снижает криптографическую стойкость (сужает выходное множество значений).