Хранение паролей в открытом виде (не понимаю)

[Hephaestus]

Пароли в открытом виде хранят pidgin, mutt, amule (хотя здесь могу ошибиться, не помню) и, видимо, многие другие программы тоже.
И как будто это так и надо.
На сайтах pidgin и ejabber даже есть какие-то объяснения по этому поводу
ejabber: "хранить пароль в открытом виде и передавать в зашифрованном надёжнее, чем наоборот"
pidgin: "другие программы хранят зашифрованный пароль, но взламывают их ничуть не меньше, поэтому смысла шифровать нету"
Это насколько я правильно понял текст на английском.

Чего-то я не понимаю.
Если открытый пароль хранить ничуть не хуже, чем зашифрованный, какого черта тогда шифруются пароли пользователей в системе, да ещё с определенными требованиями?
А если пароли шифровать всё-таки надо, то почему это не делают и не собираются? Что так трудно в конфиге хранить хеш вместо пароля?
Зашифровать одну короткую строчку - это не самая трудная операция и не самая затратная с точки зрения ресурсов.

Тем не менее, похоже, что хранение открытых паролей - это принципиальная позиция во многих случаях, стало быть, есть в этом какой-то смысл.
Но я не понимаю.

Можно, конечно, вспомнить про UNIX-way и сказать, что шифрование паролей - это отдельная задача, что надо использовать менеджеры паролей и т.п.
Это всё правильно. Вопрос только один: Зачем программа хранит пароль в открытом виде? Всё-таки пароль - это важная штука и не слишком большая для обработки. Не умеешь надёжно сохранить - не сохраняй вообще. А берёшься хранить - изволь хранить как положено - с шифрованием или хотя бы в виде md5.

Какие будут мнения?

[drBatty]

Чего-то я не понимаю.

угу. Вы не понимаете того, что зашифровать пароль невозможно. Это деление на ноль. Т.е. можно конечно. Другим паролем. А тот, другой пароль как?

Потому, в OpenSource пароли и не шифруют, а вот в платных программах "шифруют", для того, что-бы было проще объяснить заказчику, что шифрование паролей не имеет смысла. Проще "зашифровать", и спокойно получить бабло, чем объяснить заказчику, что он дебил, и остаться без бабла.

какого черта тогда шифруются пароли пользователей в системе, да ещё с определенными требованиями?

опять-таки для дебилов. На самом деле, они НЕ шифруются. Получить зашифрованный файл можно, если знать пароль. Получить "зашифрованный" пароль НЕЛЬЗЯ. В принципе НЕЛЬЗЯ. Потому-что функция "шифрования" (правильно называть её -- криптостойкий хеш) по определению НЕОБРАТИМА. Это для неё основное требование(есть и другие).

Т.о. невозможно узнать пароль по его хешу. Однако хеш по паролю -- можно. Откуда вывод: любой пароль можно найти подбором. Откуда следствие: пароль должен быть длинным. Откуда следствие: IRL пароль подбором найти НЕЛЬЗЯ. Конечно при условии, что все всё делают правильно (исключая криптоаналитика, у которого одно правило -- не использовать магию. Всё остальное -- можно)

От пользователя требуется всего-ничего: придумать пароль в 8 символов или более, которого нет В ЛЮБЫХ словарях. От программиста требуются некоторые дополнительные телодвижения, ибо такой пароль подобрать на сегодня таки возможно. С бюджетом около $200. Это если программист -- дурак.

Что так трудно в конфиге хранить хеш вместо пароля?

трудно. Т.е. хранить конечно не трудно, но вот у меня сейчас проблема: на компьютере жены transmission, у меня есть к нему доступ по ssh, и через клиент. Но через клиент настройки не очень полны, некоторых не хватает. Вопрос: как мне запустить локальный клиент на компьютере жены? Учитывая, что пароль я не помню, знаю только этот долбанный хеш.

Решение -- изменить жене пароль, а потом изменить его в своём клиенте. А ещё я точно не знаю, знает-ли жена этот пароль, и нужен-ли он ей? Если её спросить, она обидется, и скажет: "почему ты пароли меняешь, ты мне разве не веришь?". А если он ей не нужен, то тоже обидеться, и скажет: "почему ты мне не сказал этот пароль?". Короче -- куда не кинь -- везде клин.

В Linux файл с паролем можно (и нужно!) защищать иначе: правами 0600 на файле. Тогда его может прочесть только хозяин. Если вы хотите лишить какого-то юзера права -- смените хозяина этого файла. Ну например создайте юзера transmission, в которого вообще никак нельзя войти, кроме как руту, через sudo -u transmission transmission-daemon.

Если есть необходимость, откройте иксы для юзера transmission(man xhosts), и пропишите себе в sudo правило разрешающее вам, на вашем компбьютере, запускать программу transmission-gtk, от имени юзера transmission. Если вам хочется локально работать с этим приложением, и не в консоли, а в гуе.

Зашифровать одну короткую строчку - это не самая трудная операция и не самая затратная с точки зрения ресурсов.

ненужная и неудобная операция. Всё равно, что свою дверь дерьмом обмазать, чтоб воры не залезли.

[drBatty]

есть в этом какой-то смысл.

у безопасности две задачи:

• усложнить жизнь врагу
• упростить жизнь хозяину

Про вторую задачу вы почему-то забыли. Каким образом хеширование пароля усложнит жизнь врагу, если у него и так полный доступ к файлу с хешем?

Таким образом, хеширование паролей нужно тогда, и только тогда, когда мы вынуждены дать врагу право чтения файла. Например, враг напавший на вебсервер может прочитать файлы этого сервера, и его БД. Потому-то там пароли и хешируются. А если юзер напал на ваш компьютер, и если получил доступ к вшей учётке, и если из-под этой учёткой вы запускаете свой джаббер, то смысла скрывать пароль нет никакого. Враг в вашей учётке совершенно не отличим от вас, и его программа тоже не отличима от вашего джаббера. И потому система не может и не должна защищать пароль от такого врага, ибо не может его отличить от вас. И даже если джаббер станет хранить пароль в виде хеша, то всё равно враг может:
1. его заменить на свой
2. враг может вырубить джабер(вы же можете!), и запустить неотличимую обманку, в которую ВЫ САМИ введёте этот пароль.

Зачем программа хранит пароль в открытом виде? Всё-таки пароль - это важная штука и не слишком большая для обработки. Не умеешь надёжно сохранить - не сохраняй вообще. А берёшься хранить - изволь хранить как положено - с шифрованием или хотя бы в виде md5.

программе глубоко параллельно, КАК хранить пароль. Хранить его в виде хеша ВНЕЗАПНО проще. Почему? А потому, что сравнить два ЧИСЛА проще, чем строку с хрен знает чем. Потому программе проще обратить "хрен знает что" в число(md5), а потом сравнивать числа. Ибо иначе может быть например переполнение буфера, или ещё что-то плохое. Вплоть до выполнения вредоносного кода, который был введён в поле пароля. Ну а с числом ничего подобного не бывает, и быть не может. Число всегда занимает M битов, и сравнивать их тривиально и просто. В отличие от строк, особенно utf-8, особенно регистроНЕзависимых. Любое такое сравнение == потенциальная ДЫРА, или в лучшем случае просто баг.

И тем не менее, программисты идут на усложнения, для удобства пользователей. Хотя пользователи, как всегда, этого не ценят.

[ice2000]

Я храню пароли в текстовом файле на диске, даже если ктото попытается найти, то не найдет, данные разделены

[Bizdelnick]

Что так трудно в конфиге хранить хеш вместо пароля?

Нет, нетрудно. Трудно его из хеша восстановить. Хеширование по определению необратимо.
Что касается шифрования - оно эффективно только если используется мастер-пароль. В любом другом случае расшифровать пароль ни разу не проблема. Вот, например, забыл я как-то пароль от джабберного аккаунта. Psi его хранит в зашифрованном виде. За 5 минут нагуглил скрипт, который его расшифровал. Какой толк от такого шифрования?
А вот почему шифрование с мастер-паролем не везде используется - для меня загадка. Впрочем, у KDEшных и GNOMEовских программ с этим лучше - они обычно по умолчанию используют kwallet или gnome-keyring.

[drBatty]

Я храню пароли в текстовом файле на диске

а я -- в текстовом файле на диске, который зашифрован gpg ключом. Потому, если я свой диск "потеряю", пароли вор не сможет получить. Да, gpg ключ тоже зашифрован паролем, т.к. лежит на том же диске. И потому, каждый раз, когда мне нужен пароль, мне приходится вводить пароль к gpg ключу, что-бы посмотреть список. Доказывать, что я -- не верблюд.

Это неудобно, за то вору не достаточно просто украсть диск. Ему необходимо ещё украсть меня с моим паяльником, а это довольно затратно.

Конечно, вор может также
1. украсть диск
2. поставить обманку
3. вернуть диск обратно так, что-бы я ничего не заметил
4. опять украсть диск
Это можно, но паяльник дешевле, потому я всерьёз не рассматриваю такую угрозу.
(в принципе зря. Есть смысл ещё и подписать файлы gpg ещё одним ключом, который хранится в другом месте. Вот тогда без паяльника будет не обойтись, т.к. обманку будет не установить на систему. К примеру, можно каждый раз ставить систему по новой, или таскать её с собой. В нетбуке так оно и есть)

[drBatty]

А вот почему шифрование с мастер-паролем не везде используется - для меня загадка.

потому-что для одного пароля это не имеет смысла.

Ну а что касается менеджеров паролей, то чем ваш менеджер лучше моего? Только хуже. (напомню -- у меня простой текстовый файл, зашифрованный gpg).

Впрочем, у KDEшных и GNOMEовских программ с этим лучше - они обычно по умолчанию используют kwallet или gnome-keyring.

это для тех, у кого рука к мышке приросла, и клава сломалась. Ну и эти ваши бумажники легко и не принуждённо подменяются. Т.е. очень просто сделать kwallet, который для вас -- kwallet, а ещё и мне ваши пароли присылает. А ставится он из моего локального репозитория, который на вашем диске, и подписан моим ключом, тоже на вашем диске.

Да, у вас подпись проверяется, но вы же не знаете, КАКАЯ? И ЧЬЯ? Вам -- всё равно. Программа ведь проверяет, а не вы. У меня тоже программа, вот только у меня она проверяет не просто ключом, а подписанным Мною ключом Патрега. И подписывал я его ручками. Вы так не сможете, даже имея мою систему.

[Bizdelnick]

Ну а что касается менеджеров паролей, то чем ваш менеджер лучше моего? Только хуже. (напомню -- у меня простой текстовый файл, зашифрованный gpg).

Мой? Я где-то упоминал мой менеджер паролей? Вроде нет... Если интересно - я использую скриптик под названием pass (есть вроде только в убунтовских репах, ну и нагуглить можно). Каждый пароль хранится в отдельном текстовом файле, зашифрованном gpg. Ну и в Iceweacel пароли сохраняю с мастер-паролем.

Ну и эти ваши бумажники легко и не принуждённо подменяются. Т.е. очень просто сделать kwallet, который для вас -- kwallet, а ещё и мне ваши пароли присылает.

Что мешает точно так же подменить gpg? Не вижу никакой разницы. Но в обоих случаях надо ещё в систему проникнуть тем или иным образом.

[ice2000]

Если пароль сложный , то дешифровать его без больших затрат сложно
Большинство атак это атаки по словарю , это дает быструю дешифровку
Если скажем пароль 30 случайных знаков, то выдрать его невозможно, если он хеширован даже md5

[drBatty]

Если интересно - я использую скриптик под названием pass (есть вроде только в убунтовских репах, ну и нагуглить можно). Каждый пароль хранится в отдельном текстовом файле, зашифрованном gpg.

интересно. А что этот скрипт делает? Я как делаю:

1. vim /tmp/pass.txt и там вбиваю пароль и прочую ерунду.
2. gpg --encrypt
3. mv /tmp/pass.txt хранилище/

Мне не очень понятно, зачем тут вообще скрипт?

Что мешает точно так же подменить gpg?

ничего не мешает. Но и даст одно это немного. Потому-что вам придётся предугадать ТОЧНЫЙ сценарий моих действий с gpg, что-бы она действовала ТАК, как обычная. Но В НУЖНЫЙ момент повела-бы себя как-то иначе(например пароль слила бы, либо наоборот, НЕ проверила-бы, а лишь сделала-бы вид, что проверила). Сценарий НИГДЕ не записан, я сам не знаю, что буду делать, за то отлично знаю, что из этого получится. А если что-то пойдёт не так, я засомневаюсь, и сразу же обнаружу заразу(ну или скорее исправлю сгоревшее оборудование, потому-что я на него подумаю. А если оборудование в порядке, значит с программой что-то не так. А если эта программа -- gpg, то всю систему можно выбросить, и взять новую)

Проблема всех этих ваших скриптов/бумажников в их ПРЕДСКАЗУЕМОСТИ. Я отлично знаю, как будет себя вести ВАШ скрипт, ведь вы сами признались в том, что его легко нагуглить. Единственное, чего я не знаю: как будете вести себя ВЫ. И потому, криптоанализ будет обречён на провал. Ведь меня рядом не будет, с моим любимым паяльником, вы будете один на один с теми скриптами, которые я для вас напишу. Даже если вы ничего не подозреваете, то последовательность ваших действий непредсказуема. В отличие от того, что будет делать ваш скрипт(бумажник).

Важно отметить, что данная защита сама по себе информацию НЕ защищает, она лишь осложняет удалённую (по времени И по расстоянию) атаку. А если ваши действия не детерминированны, то делает атаку (почти)невозможной(возможна лишь полностью пассивная атака, когда производится лишь сбор данных. Да и то, в Linux'е она сильно усложнена тем, что там процессы как на ладони, и потому спрятать процесс не слишком просто. Ну и ещё Over9000 инструментов мониторинга, причём нет никакой возможности угадать, КАКОЙ именно будет использован. Ибо типичный администратор о 95% инструментах тупо не знает. Но эти 5% у каждого свои)

Правда для всего этого нужен грамотный админ, который регулярно мониторит свои системы. САМ, РУЧКАМИ. Вот от такого сложно что-то спрятать. А от такого, который нагуглил какую-то NIH, которая ему пишет по утрам "всё хорошо", спрятать можно живого мамонта между двумя любыми битами.

[Bizdelnick]

интересно. А что этот скрипт делает? Я как делаю:

1. vim /tmp/pass.txt и там вбиваю пароль и прочую ерунду.
2. gpg --encrypt
3. mv /tmp/pass.txt хранилище/

Мне не очень понятно, зачем тут вообще скрипт?

Чтобы вместо трёх команд использовать одну. Плюс некоторые плюшки, например можно копировать пароль в иксовый буфер обмена на ограниченное время, не отображая его на экране. И при вводе он также не отображается.

ничего не мешает. Но и даст одно это немного. Потому-что вам придётся предугадать ТОЧНЫЙ сценарий моих действий с gpg, что-бы она действовала ТАК, как обычная. Но В НУЖНЫЙ момент повела-бы себя как-то иначе(например пароль слила бы, либо наоборот, НЕ проверила-бы, а лишь сделала-бы вид, что проверила). Сценарий НИГДЕ не записан, я сам не знаю, что буду делать, за то отлично знаю, что из этого получится. А если что-то пойдёт не так, я засомневаюсь, и сразу же обнаружу заразу(ну или скорее исправлю сгоревшее оборудование, потому-что я на него подумаю. А если оборудование в порядке, значит с программой что-то не так. А если эта программа -- gpg, то всю систему можно выбросить, и взять новую)

Security by obscurity? Ну-ну.

[drBatty]

Если пароль сложный , то дешифровать его без больших затрат сложно

обычные 6..8и символьные пароли с лёгкостью ломаются за несколько секунд. Се ля ви.

Большинство атак это атаки по словарю , это дает быструю дешифровку

это нецеленаправленные атаки -- ползает бот по Сети, и тыкается. Да, по словарю. Целенаправленный взлом намного сложнее отразить. Даже не надейтесь, что вашего пароля не найдётся в словаре. Найдётся.

Если скажем пароль 30 случайных знаков, то выдрать его невозможно

на сегодня хватит и 10. И даже 7и, с русскими буквами. Если конечно криптоаналитек не из КГБ, и не drBatty с паяльником.

[Hephaestus]

угу. Вы не понимаете того, что зашифровать пароль невозможно. Это деление на ноль. Т.е. можно конечно. Другим паролем. А тот, другой пароль как?

Потому, в OpenSource пароли и не шифруют, а вот в платных программах "шифруют", для того, что-бы было проще объяснить заказчику, что шифрование паролей не имеет смысла. Проще "зашифровать", и спокойно получить бабло, чем объяснить заказчику, что он дебил, и остаться без бабла.

Не шифруют? Ну, в строгом смысле, может и не шифруют, но в /etc/shadow всё-таки нет паролей в открытом виде.

трудно. Т.е. хранить конечно не трудно, но вот у меня сейчас проблема: на компьютере жены transmission, у меня есть к нему доступ по ssh, и через клиент. Но через клиент настройки не очень полны, некоторых не хватает. Вопрос: как мне запустить локальный клиент на компьютере жены? Учитывая, что пароль я не помню, знаю только этот долбанный хеш.

Решение -- изменить жене пароль, а потом изменить его в своём клиенте. А ещё я точно не знаю, знает-ли жена этот пароль, и нужен-ли он ей? Если её спросить, она обидется, и скажет: "почему ты пароли меняешь, ты мне разве не веришь?". А если он ей не нужен, то тоже обидеться, и скажет: "почему ты мне не сказал этот пароль?". Короче -- куда не кинь -- везде клин.

Это речь идет о пароле пользователя в системе, так?
Во-первых, я не понимаю, зачем Вам удаленно запускать локальный клиент от учетки жены, ну да ладно. Если Вы имеете доступ рута в той системе, то сможете запустить любую программу от имени любого пользователя без всяких паролей, не?

Если есть необходимость, откройте иксы для юзера transmission(man xhosts), и пропишите себе в sudo правило разрешающее вам, на вашем компбьютере, запускать программу transmission-gtk, от имени юзера transmission. Если вам хочется локально работать с этим приложением, и не в консоли, а в гуе.

У меня, в принципе, так и сделано. Только не transmission.

Таким образом, хеширование паролей нужно тогда, и только тогда, когда мы вынуждены дать врагу право чтения файла. Например, враг напавший на вебсервер может прочитать файлы этого сервера, и его БД. Потому-то там пароли и хешируются. А если юзер напал на ваш компьютер, и если получил доступ к вшей учётке, и если из-под этой учёткой вы запускаете свой джаббер, то смысла скрывать пароль нет никакого.

Я правильно понимаю, что если у меня дома не web-сервер 24/7, то в /etc/shadow вполне могли бы быть пароли в открытом виде?

Нет, нетрудно. Трудно его из хеша восстановить. Хеширование по определению необратимо.

Итак, на сервере авторизации хранится логин и стойкий хеш от пароля, при запросе программа-клиент отправляет пару логин+пароль в открытом виде, сервер берет логин, вычисляет хеш от пароля, сравнивает с тем, что хранится, в случае успеха - авторизует. То есть сервер пароль получает в открытом виде - это обязательное условие.
Если программа-клиент хранит не сам пароль, а его хеш, то пароль нужно восстанавливать из хеша либо клиенту перед отправкой, либо серверу при получении.
Примерно так? Правильно понимаю?
Противоречие налицо: необходимость хранить пароль открыто (иначе серверу не отправишь) и одновременно необходимость пароль шифровать (ведь хранить пароли в открытом виде опасно, с этим, вроде, никто не спорит).
Коли так, то пароль в конфигах клиента лучше не хранить совсем.

а я -- в текстовом файле на диске, который зашифрован gpg ключом. Потому, если я свой диск "потеряю", пароли вор не сможет получить. Да, gpg ключ тоже зашифрован паролем, т.к. лежит на том же диске. И потому, каждый раз, когда мне нужен пароль, мне приходится вводить пароль к gpg ключу, что-бы посмотреть список. Доказывать, что я -- не верблюд.

Мда, при использовании mutt или pidgin удобнее, когда пароль не спрашивают.
Если хранить в зашифрованном файле, то надо каждый раз при запуске почтового клиента надо вводить пароль от ключа.
Тогда уж чего проще - вводить каждый раз пароль от ящика, не всё ли равно.
Другое дело, если ящиков несколько - здесь, наверно, удобнее вводить один пароль от ключа.

[drBatty]

Чтобы вместо трёх команд использовать одну.

дык посчитайте число нажатий на кнопки(с учётом автокомплита), у меня столько же нажатий. Имя файла вбивать надо? Пассфразу вбивать надо? Пункт назначения надо? Ну то на то и выйдет, +-10%.

Да, можно наделать няшных менюшек, но в данном случае это баг, а никакая не фича.

Security by obscurity? Ну-ну.

да я знал, что вы это скажите. Тогда скажите, что именно вам непонятно? Ну вот например, может вам непонятен какой-то из алгоритмов, которые используются в gpg? Да все алгоритмы понятны, КАКОЙ я буду использовать? Мне -- всё равно, gpg тоже, она все умеет. А вот вашей обманке -- увы. Потому-что она этого НЕ ЗНАЕТ.

А вы путаете НЕПОНИМАНИЕ и НЕЗНАНИЕ. Я вам просто НЕ СКАЗАЛ, какой я использую алгоритм, и вот потому-то вы его не сможете подделать. При чём тут "(не)понимание"?

Список алгоритмов вполне известен, и вы можете сделать подделку, подписав его одним из своих ключей по одному из этих алгоритмов. Я даже этого и не замечу, если алгоритм вы угадаете как у меня, и если ключ будет похожим, я же не всматриваюсь каждый раз... Вот у Патрега 40102233, если вы мне подсунете 40103322, я возможно и не замечу. А какой ID у меня? Да, внутреннюю ерунду я не тем подписываю, что под аватаркой, и какой-бы вы не поставили, он и рядом не будет лежать с моим. Уверен, что метрика будет не меньше 16, т.е. на глаз -- абсолютно другое.

Тот же метод применяется и для ssh, там ещё и визуализация есть (потому-что у меня всего два ключа для подписи, и их я зрительно помню, но вот хостов намного больше, и всех невозможно запомнить по fingerprint)

Это всё защита основывающаяся на НЕЗНАНИИ, а вовсе не на "непонятности". Я же ничего не маскирую, не прячу. Вы хоть убейтесь, но не найдёте например этого ID, потому-что я его никогда и нигде не публиковал. Как и скажем пароля какого-то. Украсть-то его конечно можно в оффлайне, но вот обратно отдать -- я не очень понимаю, КАК?

[Bizdelnick]

Итак, на сервере авторизации хранится логин и стойкий хеш от пароля, при запросе программа-клиент отправляет пару логин+пароль в открытом виде, сервер берет логин, вычисляет хеш от пароля, сравнивает с тем, что хранится, в случае успеха - авторизует. То есть сервер пароль получает в открытом виде - это обязательное условие.
Если программа-клиент хранит не сам пароль, а его хеш, то пароль нужно восстанавливать из хеша либо клиенту перед отправкой, либо серверу при получении.
Примерно так? Правильно понимаю?

Да, так.

[drBatty]

Не шифруют? Ну, в строгом смысле, может и не шифруют, но в /etc/shadow всё-таки нет паролей в открытом виде.

там хеши и соль в открытом текстовом виде. А рядышком понятный man 1 passwd, ещё и по-русски, если вам что-то НЕПОНЯТНО.

Решение -- изменить жене пароль, а потом изменить его в своём клиенте. А ещё я точно не знаю, знает-ли жена этот пароль, и нужен-ли он ей? Если её спросить, она обидется, и скажет: "почему ты пароли меняешь, ты мне разве не веришь?". А если он ей не нужен, то тоже обидеться, и скажет: "почему ты мне не сказал этот пароль?". Короче -- куда не кинь -- везде клин.

Это речь идет о пароле пользователя в системе, так?

нет. Это про пароль удалёнки transmission.

Во-первых, я не понимаю, зачем Вам удаленно запускать локальный клиент от учетки жены, ну да ладно.

у неё свой компьютер, у меня свой компьютер. Кино лежит на её компьютере. Удалённый клиент я запускаю со своего компьютера, а демон на её. Управляет-ли она торрентами со своего -- я не помню. Если и управляет, то редко. Возможность у неё такая есть -- запускать локально удалённый клиент. А вот надо ей это, или не надо -- не знаю.

Если Вы имеете доступ рута в той системе, то сможете запустить любую программу от имени любого пользователя без всяких паролей, не?

могу конечно. Ну дык это надо мне её гнать с её же компьютера, и оттуда запускать клиент. Или пробрасывать туда свои иксы по ssh, что-бы там запускать гуй, а смотреть у себя. Я не говорю, что это "нельзя", я говорю: "неудобно". Ну а просмотр файла с настройками даёт мне вот это: "a0c96097de4e4465fb67156e2be6e3f5W3zpACQ9". А в моём удалённом гуе нету фишки "сменить пароль". Это надо transmission-daemon -v new_pass вбивать, и тогда пароль сменится. Но и жена тоже обидится, т.к. ЕЁ уже туда очевидно не пустят, с её клиентом.

А вот rm -rf / я могу без проблем запускать, это да. Права у меня есть.

Я правильно понимаю, что если у меня дома не web-сервер 24/7, то в /etc/shadow вполне могли бы быть пароли в открытом виде?

нет, НЕПРАВИЛЬНО! Потому-что ЭТОТ файл должен быть доступен ВСЕМ, даже тем, кто НЕ авторизовался (есть, правда, костыли вроде pam, но это уже костыли). Как программа login будет проверять правильность пароля? Если юзер ЕЩЁ не зашёл? Без костылей(SUID, pam, ...) -- это не возможно. Т.к. что-бы проверить, надо прочитать. А если есть право прочитать, то смысл проверять?

Итак, на сервере авторизации хранится логин и стойкий хеш от пароля, при запросе программа-клиент отправляет пару логин+пароль в открытом виде, сервер берет логин, вычисляет хеш от пароля, сравнивает с тем, что хранится, в случае успеха - авторизует. То есть сервер пароль получает в открытом виде - это обязательное условие.

нет, это НЕ обязательное условие.

Схема неуязвима от атаки, когда враг проникает в систему, и читает пароль из /etc/passwd.

Но схема уязвима от атаки с помощью перехвата, когда враг снифает трафик, по которому идёт пароль.

Что-бы избавится, нам надо как-нить зашифровать пароль. А сервер расшифрует. Вот например в SSH так и делается: у сервера есть пара ключей, и он отправляет открытый ключ клиенту. Клиент шифрует пароль, и отправляет серверу, сервер расшифровывает пароль закрытым ключом, который есть только у него.

Схема уязвима от подмены самого сервера. Мы можем зайти НЕ ТУДА, и зашифровать пароль НЕ ТЕМ ключом. Тогда враг его узнает, и сможет быстренько зайти ТУДА, используя ваш пароль. Вам будет казаться, что всё хорошо. Но на самом деле -- всё плохо. Для защиты от этой атаки, нужно отправить СВОЙ ключ на сервер, и тогда врага не пустят. Т.к. только вы можете доказать, что это ваш ключ.

Но эта схема требует отправки ключа на сервер. Потому не применяется для web. Для web применяется TLS, т.е. подпись ключа сервера третьей стороной, известной и клиенту. Тогда клиент может проверить, тот-ли сервер, или это подмена.

Если программа-клиент хранит не сам пароль, а его хеш, то пароль нужно восстанавливать из хеша либо клиенту перед отправкой, либо серверу при получении.

нет, не нужно ничего восстанавливать. Когда вы настраиваете сервер, вы получаете из пароля 33b02bc15ce9557d2dd8484d58f95ac4, а когда клиент вводит пароль, он(или сервер) получает хеш 33b02bc15ce9557d2dd8484d58f95ac4, который сравнивается с сохранённым. Откуда и следует вывод, что пароль(в данном случае 'zzz'), был введён правильно.

Но если злоумышленник сниффает канал, то нет никакой разницы, передаёте вы 'zzz', или 33b02bc15ce9557d2dd8484d58f95ac4, потому-что для сервера надо 33b02bc15ce9557d2dd8484d58f95ac4, и врагу подойдёт и то и другое.

Противоречие налицо: необходимость хранить пароль открыто (иначе серверу не отправишь) и одновременно необходимость пароль шифровать (ведь хранить пароли в открытом виде опасно, с этим, вроде, никто не спорит).

так вы от атаки при ХРАНЕНИИ защитится хотите, или от атаки при ПЕРЕДАЧЕ? Если второе, то хеш вам НЕ поможет. Если первое -- поможет.

Коли так, то пароль в конфигах клиента лучше не хранить совсем.

т.е. "заходи кто хочет"? Не... Хранить что-то надо. И лучше именно пароль в открытом виде, если вход удалённый.

>Мда, при использовании mutt или pidgin удобнее, когда пароль не спрашивают.

что касается pidgin, то он у меня сам пароль хранит. Кстати -- в открытом виде.

Что касается mutt, то он у меня почту не принимает, а принимает fetchmail, который тоже пароль хранит в открытом виде(передаёт по ssl/tls, для защиты от перехвата).

Во время отправки почта шифруется и/или подписывается, и для подписи приходится ручками пассфразу набирать, да. Для шифрования -- естественно не нужно ничего набирать, ведь я всё равно не знаю пассфразу того, кому пишу. И ключа у меня его нет.

[drBatty]

Если программа-клиент хранит не сам пароль, а его хеш, то пароль нужно восстанавливать из хеша либо клиенту перед отправкой, либо серверу при получении.
Примерно так? Правильно понимаю?

Да, так.

что вы человеку голову морочите? Он думает, что "пароль нужно восстанавливать из хеша", а это -- бред. Это в принципе невозможно.

[drBatty]

и да. В итоге:

• Пароль == неизвестная врагу информация (потому строка "123" -- не пароль, ибо её просто подобрать)
• При передачи пароль НУЖНО шифровать, и хорошо шифровать(от пользователя тут ничего не зависит, а админу достаточно НЕ использовать протоколы где пароль не шифруется(e.g. FTP), или плохо шифруется(e.g. samba), что собственно одно и то же. Использовать md5(sha512 и т.п.) тоже нельзя, ибо это хорошие хеши, но совсем не шифр.
• Хранить пароли на сервере нельзя, можно хранить только хеш+соль. Длинна соли должна быть достаточной(8+ символов), т.к. юзеры любят использовать пароли типа 123(да, это не пароль, но свою голову другим не приставишь).
• Хранить пароли на клиенте лучше не надо, но приходится, ибо иначе их надо постоянно вбивать, что не удобно(или невозможно для автоматических программ). Можно хранить пароли в памяти, как компромиссное решение. Тогда их придётся расшифровывать не очень часто. Если эта память отображается в ФС, то права на файлы должны быть 0600, на каталоги 0700, а владельцем должен быть тот, кто запускает программы, использующие данные пароли. Желательно, что-бы у всех таких программ были разные владельцы. Также желательно, что-бы в учётку владельца было невозможно зайти иначе, чем через эту программу.

[NoVASpirit]

Почему обязательно шифровать пароли gpg ключами? Неужели нельзя просто заархивировать в 7z с одним паролем?

[Bizdelnick]

Почему обязательно шифровать пароли gpg ключами? Неужели нельзя просто заархивировать в 7z с одним паролем?

А Вы считаете, что там ключа нет? Так глубоко заблуждаетесь: он есть, симметричный, и хранится в самом зашифрованном файле. Единственное отличие в том, что в 7z (или любой программе с мастер-паролем) симметричный ключ шифруется паролем, а в gpg по умолчанию - асимметричным ключом. В случае, когда файл с паролем создаётся и читается одним и тем же пользователем, асимметричное шифрование действительно излишне. Но у gpg есть опция --symmetric, с помощью которой можно использовать шифрование симметричного ключа паролем, без асимметричного ключа.

[drBatty]

Почему обязательно шифровать пароли gpg ключами?

ну во первых потому-что это удобно: gpg умеет шифровать без запроса пароля и секретного ключа. Т.е. можно шифровать где угодно и для кого угодно, включая автоматический режим без оператора.

Неужели нельзя просто заархивировать в 7z с одним паролем?

а где хранить этот пароль?

Ну и шифрование 7z -- ненадёжно. 7z это ваще-то архиватор.

[drBatty]

В случае, когда файл с паролем создаётся и читается одним и тем же пользователем, асимметричное шифрование действительно излишне.

это вы так думаете. А я знаю. Например файл с паролями можно хранить в /tmp/, и автоматически сбрасывать на диск. Как это сделать с симметричным шифрованием? Каждый раз пароль вбивать?

Но у gpg есть опция --symmetric, с помощью которой можно использовать шифрование симметричного ключа паролем, без асимметричного ключа.

есть конечно. Ещё есть опция --passphrase-file для того, что использовать файл в качестве пароля. Оно конечно плохо для безопасности, но всё же лучше, чем пароль на каждый чих ручками вбивать.

[Bizdelnick]

Ну и шифрование 7z -- ненадёжно. 7z это ваще-то архиватор.

А какая разница? Там используется AES с 256-битным ключом. В gpg ЕМНИП по умолчанию тоже.

[drBatty]

А какая разница? Там используется AES с 256-битным ключом. В gpg ЕМНИП по умолчанию тоже.

криптография == наука о нюансах. Просто "AES256" недостаточно, дьявол в деталях. Достаточно всего одной маленькой дырочки. Этот ваш 7z спасает только то, что никто его всерьёз не воспринимает, и не использует. Потому и не атакуют. Как раз ваша "безопасность через неясность".

Но дело даже не в этом. Симметричное шифрование нестойко по определению, ибо вам нужно
1. постоянно помнить пароль
2. постоянно его вбивать
3. пароль везде будет ОДИН
В принципе, даже одного любого этого пункта достаточно, что-бы признать симметричное шифрование негодным для практики.

Игрушка...

[Bizdelnick]

Но дело даже не в этом. Симметричное шифрование нестойко по определению, ибо вам нужно
1. постоянно помнить пароль
2. постоянно его вбивать
3. пароль везде будет ОДИН
В принципе, даже одного любого этого пункта достаточно, что-бы признать симметричное шифрование негодным для практики.

Видимо, слишком глубокая для меня мысль. Не осознал.

[NoVASpirit]

Да вы заархивируйте в 7z и проверьте сколько уйдет времени. чтобы подобрать пароль к архиву....

Да и помнить один пароль, чтобы открыть тысячу паролей всяко лучше....

[Bizdelnick]

Да вы заархивируйте в 7z и проверьте сколько уйдет времени. чтобы подобрать пароль к архиву...

Дело не в этом, а в использовании инструмента не по назначению. Никаких преимуществ по сравнению с gpg он не даёт.

[drBatty]

Видимо, слишком глубокая для меня мысль. Не осознал.

специально разбил на пункты. Какой именно непонятен?

[drBatty]

Да вы заархивируйте в 7z и проверьте сколько уйдет времени. чтобы подобрать пароль к архиву....

для этого мне придётся ковырять ваш маздайный 7z, и искать там уязвимости. Зачем мне это?

Да и помнить один пароль, чтобы открыть тысячу паролей всяко лучше....

но ещё лучше НЕ помнить этого пароля.

Дело не в этом, а в использовании инструмента не по назначению. Никаких преимуществ по сравнению с gpg он не даёт.

преимущества даёт асимметричный метод шифрования. Только он позволяет сделать шифрование автоматическим, без участия администратора.

Кроме того, только он позволяет шифровать файлы для разных хранилищ разными паролями. А симметричный -- только одним паролем на всё.

7z не умеет асимметричный метод, а значит -- не нужен для практического использования.

Да и помнить один пароль, чтобы открыть тысячу паролей всяко лучше....

а что-бы ЗАКРЫТЬ?

[Hephaestus]

там хеши и соль в открытом текстовом виде.

Хеши и соль - да, но не пароли в открытом виде

нет, не нужно ничего восстанавливать. Когда вы настраиваете сервер, вы получаете из пароля 33b02bc15ce9557d2dd8484d58f95ac4, а когда клиент вводит пароль, он(или сервер) получает хеш 33b02bc15ce9557d2dd8484d58f95ac4, который сравнивается с сохранённым. Откуда и следует вывод, что пароль(в данном случае 'zzz'), был введён правильно.

Я не настраиваю сервер. Я использую почтовый сервер, скажем, mail.yandex.ru и почтовый клиент - mutt.

так вы от атаки при ХРАНЕНИИ защитится хотите, или от атаки при ПЕРЕДАЧЕ?

При хранении.

т.е. "заходи кто хочет"?

Ни в коем случае. Пароль нигде не хранится, запрашивается каждый раз.

что вы человеку голову морочите? Он думает, что "пароль нужно восстанавливать из хеша", а это -- бред.

Не думаю я так. Сформулирую точнее: пароль пришлось бы восстанавливать из хеша, если бы тот же mutt хранил хеш, а не пароль в открытом виде.