The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск механизма управления теневыми паролями tcb 1.2, opennews (??), 12-Янв-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


49. "Выпуск механизма управления теневыми паролями tcb 1.2"  +5 +/
Сообщение от solardiz (ok), 12-Янв-21, 17:50 
> Сомнительно, у пользователя не должно быть прав на запись в системные каталоги.

Их и нету. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---".

> А blowfish вроде старенький, уже лет 15 как считается совсем не секурным.

1. Не путайте блочный шифр Blowfish и парольный хеш bcrypt на его основе. У них совсем разные свойства. В данном контексте, речь о bcrypt.

2. Конечно, и Blowfish и bcrypt старенькие, но с ними в целом всё в порядке. Основной недостаток Blowfish как шифра в маленьком размере блока (64 бита) - см. https://sweet32.info и https://blog.cryptographyengineering.com/2016/08/24/attack-o.../ - это 2016 год. К bcrypt этот недостаток отношения не имеет.

3. tcb никак на bcrypt не завязан, он лишь использует универсальный API, который мы первоначально реализовали в crypt_blowfish (реализации bcrypt). Теперь этот API доступен в libxcrypt и позволяет tcb использовать любой из поддерживаемых в libxcrypt парольных хешей, в том числе наш yescrypt.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

67. "Выпуск механизма управления теневыми паролями tcb 1.2"  +/
Сообщение от Аноним (-), 13-Янв-21, 01:42 
А разве blowfish не использует массивы для пермутации? И если да - у этого на процессорах с кэшом заведомо есть проблемы с тайминг атаками. Сам автор его не советует.
Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск механизма управления теневыми паролями tcb 1.2"  +1 +/
Сообщение от solardiz (ok), 13-Янв-21, 02:20 
Насчет cache timing, да, есть такое. Вот только в bcrypt эта же особенность существенно повышает стоимость offline атак на хеши, так что получается своеобразный security vs. security trade-off. Реально пока что cache timing атаки in the wild не встретишь (потому что не практично), а вот offline атаки на хеши - везде, как только хеши утекут. Аналогичный trade-off присутствует и для более современных схем хеширования паролей - например, из-за него существуют Argon 2i, 2d, и 2id - разный баланс между cache timing safety и защитой от offline атак.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру