«Не заставляйте меня помнить!» — Свобода пользовательским паролям
В воображаемом мире нефункциональных требований «безопасность» всегда ведет смертельный бой с «юзабилити», или говоря простыми словами — попытки сделать удобно, создают уязвимости, а перестраховка от возможных дыр может сделать продукт совершенно негодным.
Иногда возможны компромисы, но в случае конфликтов, мы всегда на стороне наших пользователей. Fresh — дистрибутив для домашних пользователей не должен изображать из себя SELinux.
Реальные риски, от которых защищаются домашние пользователи
- другой член семьи не посмотрит историю в броузере,
- если аккаунт детский, то возможно там установлена родительский надзор (SkyDNS и т.п.).
Реальная атака, если sshd не установлен (по умолчанию — нет) — ручной перебор, от чего эффективно защитит и пароль из пары-тройки символов. Да и при sshd и автоматических переборах штрафные таймауты защитят даже при «пинкодовом» пароле. Защита рутового аккаунта — только от «дурака» или потенциальных троянов.
В Fresh GNOME, и во всех других дистрибутивах, вырасших из Mandriva, была проблема, архитектурно связанная в использованием библиотеки pam_tcb.so и жестких проверок cracklib, а выглядело это так, что у пользователя
- требовалась адова секьюрность пароля (длина, наличие цифр и букв и т.п.)
- при смене обычным пользователем своего пароля, требовалось вводить дополнительно root-овый пароль — что либо выглядело издевательством, либо профанацией[1] безопасности.
Good news, everyone!
Мы сменили pam_tcb на на pam_unix, что дало возможность и
- Улучшить удобство — теперь можно делать пользователям любые пароли, система только будет оценивать его относительную сложность, и рекомендовать усиление. Но если рисков реально нет — нетбук для ребенка, с играми — то можно обойтись и без пароля поставить даже пустой пароль.
- Усилить безопасность — теперь в pam используется sha512, до этого там был вовсе bluefish-шифрование.
|
- ↑ Если каждый чих требует рутового пароля — значит этот пароль будет известен всем.
[ Хронологический вид ]Комментарии
SuperGenPass может выйти боком. 1. Вводить мастер-пароль каждый раз - будет желание сделать покороче. 2. Вероятность засветить мастер-пароль растет в (31 декабря - сложно мне сейчас сказать какой) прогрессии 3. Вы исходники смотрели?
function binl2b64(binarray) { var tab='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012345678998';Это не base64, вроде???
TLDList - это еще зачем???
4. Ну и множественность логИнов исключает напрочь. Ну, или помнить к каждому логину свой мастер-пароль :)
Я давно разбирал исходники SGP, вот, писал даже статью, скорее всего она ответит на многие ваши вопросы. Если кратко — в SGP была только одна хитрая уязвимость, но ее легко запатчить.
Войдите, чтобы комментировать.