«Не заставляйте меня помнить!» — Свобода пользовательским паролям
В воображаемом мире нефункциональных требований «безопасность» всегда ведет смертельный бой с «юзабилити», или говоря простыми словами — попытки сделать удобно, создают уязвимости, а перестраховка от возможных дыр может сделать продукт совершенно негодным.
Иногда возможны компромисы, но в случае конфликтов, мы всегда на стороне наших пользователей. 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 была только одна хитрая уязвимость, но ее легко запатчить.
Войдите, чтобы комментировать.