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

[Hephaestus]

Вот об этом

Можно хранить пароли в памяти, как компромиссное решение.

можно чуть-чуть подробнее?
Как это реализовать? Опишите хотя бы в общих чертах.

И об этом

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

А расшифровывать как? Если, к примеру, программа-клиент хранит зашифрованный пароль?
Зашифровать-то надо один раз, а расшифровывать, как минимум, при каждом запуске программы.

[drBatty]

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

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

где вы увидели слова "пароль в открытом виде", что-бы меня поправлять? Можете процитировать, я наверное ошибся, сейчас исправлю.

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

в этом случае, я не вижу причин, что-бы хранить пароль к ***@yandex.ru НЕ в открытом виде, а как-то его шифровать.

Даже если вы опасаетесь атаки ОТ СЕБЯ, то вам лучше создать отдельного пользователя для почты. Тогда вредоносный скрипт не сможет прямо взять и прочитать пароль, а ему придётся запускать через ярлык с sudo ваш mutt, что-бы отправить спама от вашего имени.

А вот если вы пароль таки зашифруете, и mutt его будет расшифровывать, то почему вы считаете, что это не сможет сделать вредоносный скрипт?

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

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

1. Вы не в состоянии запомнить достаточное количество достаточно стойких паролей. Ну может вы -- в состоянии, а у меня голова не дом советов, и запомнить Over9000 паролей типа '3B\2Wcssq' я не могу. Увы.
2. Пароль, который вы по 10 раз на дню вбиваете -- уязвим для перехвата. Всегда ваш, К.О.
3. Вы не можете использовать чужой пароль. А это полезно в 146% случаев, т.к. вам эта информация -- не нужна. У вас она и так есть. А вот пароля нет у реципиента, и ему его надо ка-то передать. Это сложно. Даже, если реципиент -- вы сами через неделю. Вам можно позавидовать, если ваш мозг способен неделю удерживать Over9000 паролей вида "7Ifu.pm1X".

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

да. Пришлось-бы поделить на ноль. А делить на ноль нельзя. Потому вы сказали ерунду.

MTU не может хранить пароль в виде хеша

потому-что этому MTU надо как-то передавать пароль MDA, что-бы этот MDA этот пароль проверял. Вот MDA может хранить только хеш, и делать из пришедшего пароля другой хеш, а потом их сравнивать. А MTU такого НЕ МОЖЕТ.

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

Но если MTU может, то почему вредоносный скрипт не может? Что ему помешает?

[Hephaestus]

нет, НЕПРАВИЛЬНО! Потому-что ЭТОТ файл должен быть доступен ВСЕМ, даже тем, кто НЕ авторизовался

Разве?
Нафига всем-то? Достаточно, чтобы был доступен программам авторизации - login или DM или что там ещё, а программа авторизации от чьего имени запущена?
Вроде как от рута. Больше доступа никому и не надо.
Авторизация - КПП с охранником. У охранника список имён и пропусков.
Всех входящих (тех кто не авторизовался) охранник проверяет по списку.
Так разве доступ к списку должен быть у ВСЕХ? По-моему только у охранника. Не?

[drBatty]

можно чуть-чуть подробнее?

сейчас попробую...

Нафига всем-то? Достаточно, чтобы был доступен программам авторизации - login или DM или что там ещё, а программа авторизации от чьего имени запущена?

вот в том-то и дело, что программа авторизации запущена "от имени" некоего "no body", т.е. абсолютно бесправного и бестелесного юзера, у которого нет НИЧЕГО. Её(программы) цель как раз и состоит в том, что-бы определить, какие именно дать права тому, кто её запустил. Это как охранник, у которого тоже нет доступа к закрытым документам. Его задача -- только проверять пропуска, и не более того. Естественно, права делать пропуска у него нет. Права делать копии пропусков -- тоже нет. IRL это обеспечивается тем, что пропуск просто прочитать, но сложно сделать копию. В CS копию сделать очень просто всегда, потому этого недостаточно, и используют необратимую функцию, а охранник сверяет результат этой функции, а вовсе не то, из чего это сделано. Да, тоже уязвимость, т.к. охранник может сохранить где-то копию пароля, а потом подсказать её кому-то другому. Потому-то у "охранника" нет мозгов, тушки, и памяти. И запоминать пароли тупо негде.

У охранника список имён и пропусков.

список имён есть. Есть также и некий "образ" пропуска, т.е. охранник знает, КАК ВЫГЛЯДИТ пропуск. Если ему показать бумажку и пропуск, он сможет сказать: "это бумажка, а это -- пропуск". Тем не менее, пропуск сделать он не может. Правильнее сказать -- может. Но только один раз. Ибо после первого-же изготовления пропуска, охранника расстреливают, и меняют новым, который ессно ничего не знает про старый пропуск.

Так разве доступ к списку должен быть у ВСЕХ? По-моему только у охранника. Не?

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

[Hephaestus]

где вы увидели слова "пароль в открытом виде", что-бы меня поправлять?

Напоминаю наш диалог:

Потому, в OpenSource пароли и не шифруют

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

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

Да, насчёт хешей и соли в открытом виде я согласен. Но ПАРОЛЕЙ в открытом виде там всё-таки нет.
Так что их (пароли) может и не шифруют, но и в открытом виде не хранят.

А вот если вы пароль таки зашифруете, и mutt его будет расшифровывать, то почему вы считаете, что это не сможет сделать вредоносный скрипт?

Конечно, пароль можно вообще не хранить, а каждый раз вбивать. Но тогда почему вы считаете, что вредоносный скрипт его не перехватит?

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

Тогда вредоносный скрипт не сможет прямо взять и прочитать пароль, а ему придётся запускать через ярлык с sudo ваш mutt, что-бы отправить спама от вашего имени.

Ну и запустит. Что, не сможет что ль? Теоретически сможет. Хотя практически трудновато - кроме пароля от sudo, надо знать имя пользователя, от которого запускается mutt.

да. Пришлось-бы поделить на ноль. А делить на ноль нельзя. Потому вы сказали ерунду.

Я просто не сразу сообразил, что сервер хранит пароли зашифрованными. Как-то вылетело из головы.

[Hephaestus]

вот в том-то и дело, что программа авторизации запущена "от имени" некоего "no body", т.е. абсолютно бесправного и бестелесного юзера, у которого нет НИЧЕГО.

Ой... Насколько я помню, DM стартует от рута - это точно. И программа login вроде тоже.
Хотя могу и ошибаться. Вечером буду дома - посмотрю внимательно, кто там как стартует.

Спасибо Вам, drBatty за то, что даёте пищу для размышлений.

[drBatty]

Да, насчёт хешей и соли в открытом виде я согласен. Но ПАРОЛЕЙ в открытом виде там всё-таки нет.
Так что их (пароли) может и не шифруют, но и в открытом виде не хранят.

в данном случае пароли вообще не хранят. Т.ч. никакого противоречия нет -- если вы забудете пароль, то вы его НИКАК не восстановите. Т.е. он НЕ СОХРАНЁН. Нигде, кроме вашей головы. Хеш -- только хитроумный матан, который позволяет ПРОВЕРИТЬ, помните-ли вы этот пароль. Вместо пароля можно использовать ваше ФИО и адрес, а вместо хеша -- специально обученного негра, который сбегает к вам домой, и проверит, врёте вы, или нет. При этом ваше ФИО хранить нигде не только не нужно, но и нельзя, в полном соответствии с новым Законом РФ о личных данных. Такая защита часто применяется IRL. И такая защита -- весьма уязвима. Но дело тут не в вас, и не в негре. Враг может например перехватить негра рядом с вашем домом, и представится вами. Тогда негр подумает, что вы -- это враг. И вы так подумаете. Но это уже другой риск.

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

то, что я этот пароль очень редко вбиваю. Зачем он мне?

Тогда вредоносный скрипт не сможет прямо взять и прочитать пароль, а ему придётся запускать через ярлык с sudo ваш mutt, что-бы отправить спама от вашего имени.

Ну и запустит. Что, не сможет что ль? Теоретически сможет. Хотя практически трудновато - кроме пароля от sudo, надо знать имя пользователя, от которого запускается mutt.

вот и я говорю -- трудновато. Безопасность через неопределённость. А в случае "зашифрованного" пароля -- через неясность, ибо в этом случае mutt с лёгкостью его расшифровывает. Значит и скрипт может также, ведь скрипт -- такая же программа. А в случае ярлыка и sudo, спам может только ваш друг отправлять из вашего дома с вашего компьютера также легко, как и вы. А вот скрипт -- увы. Потому-что скрипт не умеет раскрывать неопределённость. А друг -- умеет. Он видит, как вы это делаете. Скрипту в этом плане сложнее. И возможно такое только в научной фантастике.

Я просто не сразу сообразил, что сервер хранит пароли зашифрованными. Как-то вылетело из головы.

да перестаньте вы путать "зашифровано" и "захешировано"!

Это РАЗНЫЕ вещи!

[Bizdelnick]

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

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

[drBatty]

Ой... Насколько я помню, DM стартует от рута - это точно. И программа login вроде тоже.
Хотя могу и ошибаться. Вечером буду дома - посмотрю внимательно, кто там как стартует.

login и DM стартуют от рута конечно. Это дыра, ИМХО допустимая в бытовой технике. Но они МОГУТ запускаться от nobody, что-бы принять от юзера логин/пароль, вычислить хеш, и проверить его правильность. И рапортовать об этом системе. Система должна обеспечить три вещи:
1. проверить, что /bin/login не коррумпирована.
2. запустить /bin/login от nobody
3. если /bin/login дала добро, пустить юзера в систему как юзера.
Ну да, в бытовом линуксе попроще сделано. Ибо такой вариант -- уже клиника на дому. Имени Петра Петровича.

[Bizdelnick]

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

А пассфразу от ключа тоже не нужно?

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

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

[drBatty]

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

ok. Эти пункты являются следствием того факта, что для асимметричного шифрования не нужен пароль, а для симметричного -- нужен.

Так понятнее?

[drBatty]

Да вы заархивируйте

А пассфразу от ключа тоже не нужно?

вы выдираете слова из контекста. Это поправимо, ведь контекст удалить вы не потрудились. Потому я его восстановил.

Да, пассфразу вбивать для архивации тоже не нужно, если вы используете gpg.

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

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

Таким образом и волки сыты, и овцы целы.

[Bizdelnick]

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

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

[Hephaestus]

то, что я этот пароль очень редко вбиваю. Зачем он мне?

Ну как зачем?
У вас в зашифрованном файле 100500 суперсложных паролей, которые Вы не желаете и не можете запомнить.
По Вашим же словам

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

Насколько часто это у Вас происходит, я, конечно, не знаю.

Но для меня пароль от почты и пароль от электронного кошелька были бы одинаково ценны (это к примеру).
Как нежелательно потерять доступ к кошельку, так же нежелательно потерять доступ и к почте.
Но если кошелек нужен, скажем, раз в месяц, то почта нужна каждый день.

И, согласитесь, если через почту можно получить доступ ещё куда-то (запросить пароль), то не очень разумно пароли от "куда-то" прятать в зашифрованный файл,
а пароль от почты при этом хранить открыто в конфиге почтовой программы. Стало быть, пароль от почты тоже будет спрятан в файл. И будет расшифровываться ежедневно, если почта используется ежедневно. И запомнить его никак, ибо он длинный и сложный, потому и хранится в зашифрованном файле.
Можно, конечно, иметь специальный ящик, который будет использоваться так же редко, как и кошелёк, но... отдельный ящик для каждой цели - это обычно дело времени. Изначально ящик у человека всё-таки один.

да перестаньте вы путать "зашифровано" и "захешировано"!

Виноват, исправлюсь. Хотя разница мне известна.

Но справедливости ради скажу, что лично получал письмо от сервиса в ответ на запрос забытого пароля.
В письме было сказано что-то вроде "Мы не можем восстановить Ваш пароль, так как пароли у нас хранятся в зашифрованном виде, но Вы можете сгенерировать новый пароль, пройдя по сслыке..."
Так что может оно где-то и "зашифровано", черт его знает...

[drBatty]

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

в рекомендуемом 7z тоже так делается?

Опять вы всё передёргиваете, я про всякие keepass сказал лишь то, что они слишком непонятны, и никто не знает, КАК они работают. Потому их просто отключить, ведь пользователю важно только одно: "да/нет" на выходе. Каким-бы не были механизмы защиты, достаточно поменять "нет" на "да".

Использует keepass подпись? Да? КАКУЮ?!(не в смысле алгоритма, а в смысле -- КТО подписал?) А если это не ваша, а моя подпись? Ну и ещё Over9000 подобных вопросов.

[Hephaestus]

Ну да, в бытовом линуксе попроще сделано. Ибо такой вариант -- уже клиника на дому. Имени Петра Петровича.

Ну почему сразу клиника?
Ставит человек систему, там из коробки настроено стартовать от nobody - ну и пожалуйста.
Юзеру ведь пофигу от чьего имени стартует DM.
И почему стартовать от рута - это попроще, неясно. По-моему однофигственно.
Скрипты инициализации не переписываются каждый день. Один раз отладили с nobody и пусть работает. Зачем туда рута приплетать - создавать явную дыру?

[drBatty]

У вас в зашифрованном файле 100500 суперсложных паролей, которые Вы не желаете и не можете запомнить.

дык они в файле, файл в памяти компьютера.

e.g.

Shell

$ ll ~/.fetchmailrc -rw------- 1 drb users 2,4K окт 4 12:56 /home/drb/.fetchmailrc

там пароли к почтовым ящикам. У меня есть специальный скрипт для создания паролей, (спасибо Патрегу и Don Libes), им и делаю всякие пароли типа "zW[86edqP"

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

Насколько часто это у Вас происходит, я, конечно, не знаю.

в нетбуке -- на каждой загрузке. Впрочем, они там редкие

Код: Выделить всё

$ uptime
 13:41:48 up 1 day, 19:01,  3 users,  load average: 1.27, 1.24, 1.23

отдельный ящик для каждой цели - это обычно дело времени. Изначально ящик у человека всё-таки один.

ну это уже другой вопрос. у меня этих ящиков 2 десятка постоянно используемых.

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

Уважаемый: на заборе ещё и не то написано. Вы сами вдумайтесь в эту фразу -- "невозможно восстановить, потому-что ХРАНИТСЯ". Зачем хранить то, что нельзя восстановить? Вам мусор нужен? /dev/urandom в вашем полном распоряжении.

[Hephaestus]

дык они в файле, файл в памяти компьютера.

в нетбуке -- на каждой загрузке. Впрочем, они там редкие

А, ну если машина всё время включена, тогда всё ясно, вопросов нет.

Вы сами вдумайтесь в эту фразу -- "невозможно восстановить, потому-что ХРАНИТСЯ". Зачем хранить то, что нельзя восстановить?

Ай-яй-яй, ну зачем так искажать фразу? Невозможно восстановить не потому, что хранится, а потому что хранится в зашифрованном виде.

Зачем хранить то, что нельзя восстановить? С той же целью, с какой хранится содержимое /etc/shadow.
Из него ведь тоже пароли просто так не восстановишь. И тем не менее хранится.

[Bizdelnick]

в рекомендуемом 7z тоже так делается?

Я его не рекомендовал.

Использует keepass подпись? Да? КАКУЮ?!(не в смысле алгоритма, а в смысле -- КТО подписал?) А если это не ваша, а моя подпись? Ну и ещё Over9000 подобных вопросов.

Подпись? Зачем ещё подпись?

У меня есть специальный скрипт для создания паролей, (спасибо Патрегу и Don Libes), им и делаю всякие пароли типа "zW[86edqP"

Патрик не осилил pwgen и написал свой велосипед?

Опять вы всё передёргиваете, я про всякие keepass сказал лишь то,

Это Вы передёргиваете. Я про keepass вообще ни слова не говорил (а также никогда им не пользовался, только название слышал - вот оно зачётное, да).

[drBatty]

Ну почему сразу клиника?

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

В рассматриваемом случае, если вы НАСТОЛЬКО хотите защитить логин, то вам проще сразу вешаться. Ибо всё остальное вы защитите настолько же сильно лет через 500, а до того к компьютеру вам подходить опасно.

Ставит человек систему, там из коробки настроено стартовать от nobody - ну и пожалуйста.
Юзеру ведь пофигу от чьего имени стартует DM.
И почему стартовать от рута - это попроще, неясно. По-моему однофигственно.

потому-что надо НЕ ТОЛЬКО стартовать от nobody, надо ещё и проверять её валидность, и делать многие другие кошерные вещи. Т.е. например разрешить этому nobody доступ к клавиатуре и к монитору. Что само по себе не тривиально, т.к. тушки у него нет, а значит и к файлам клавиатуры/монитора доступа тоже нет. Ещё и доступ к памяти, что-бы было где хранить строку с логином, и строку с паролем. И что-бы куда-то загрузить libcrypto, что-бы посчитать этот хеш. Короче -- какую-то тушку сделать надо, причём очень специфическую тушку. Конечно, если вы делаете атомный реактор, то это оправдано, но для дома...

Скрипты инициализации не переписываются каждый день. Один раз отладили с nobody и пусть работает.

тут ещё "безопасность через неясность" работать будет, т.е. КАЖДУЮ такую систему надо делать уникальной, и тщательно от всех скрывать все детали работы с вашей тушкой, которой нет. А если вы не хотите использовать такой механизм как дополнительную меру, то просто запускайте от рута. В конце концов, все эти манипуляции с nobody рутом обходятся легко и непринуждённо. Если вы рут, то вы можете с лёгкостью войти под любым именем, без всяких паролей. А если это ВАШ компьютер, то вы == рут.

Смысл?

А вот если вы не рут, то тогда это уже НЕ "безопасность через неясность", а безопасность через неопределённость -- вы будете всё делать так, как оно вам указано. И взломав /bin/login получите доступ только к nobody, который вам вряд-ли что даст, кроме чтения /etc/passwd и вычисления md5 от чего угодно. Что-то может и даст, но вы НЕ ЗНАЕТЕ что. Компьютер-то не ваш...

[drBatty]

в нетбуке -- на каждой загрузке. Впрочем, они там редкие

А, ну если машина всё время включена, тогда всё ясно, вопросов нет.

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

Зачем хранить то, что нельзя восстановить? С той же целью, с какой хранится содержимое /etc/shadow.
Из него ведь тоже пароли просто так не восстановишь. И тем не менее хранится.

вдумайтесь в сам смысл русского слова "хранится", в отрыве от IT. Я это понимаю, как "охраняется от любого вида порчи". Т.е. если у меня что-то хорошо хранится, я могу это взять, и положить в карман/съесть/выпить/и т.п. Да, я согласен мириться с некоторыми трудностями, как например лезть в подпол, открывать герметично закрытую банку и т.п. Но лишь потому, что понимаю, что без этого хранится будет хуже. А именно -- испортится, и будет ненадлежащем к восстановлению. НИКАК.

Так вот, пароли в хешах если и "хранятся", то совсем в ином смысле. А именно в том, в каком "хранятся" коровьи кости в собачьих экскрементах. Да, можно узнать, что раньше ЭТО мычало и щипало траву. Но разве это -- "хранение"? ИМХО -- ну никак не хранение.

[Hephaestus]

потому-что надо НЕ ТОЛЬКО стартовать от nobody, надо ещё и проверять её валидность, и делать многие другие кошерные вещи. Т.е. например разрешить этому nobody доступ к клавиатуре и к монитору. Что само по себе не тривиально, т.к. тушки у него нет, а значит и к файлам клавиатуры/монитора доступа тоже нет. Ещё и доступ к памяти, что-бы было где хранить строку с логином, и строку с паролем. И что-бы куда-то загрузить libcrypto, что-бы посчитать этот хеш. Короче -- какую-то тушку сделать надо, причём очень специфическую тушку. Конечно, если вы делаете атомный реактор, то это оправдано, но для дома...

тут ещё "безопасность через неясность" работать будет, т.е. КАЖДУЮ такую систему надо делать уникальной, и тщательно от всех скрывать все детали работы с вашей тушкой, которой нет. А если вы не хотите использовать такой механизм как дополнительную меру, то просто запускайте от рута. В конце концов, все эти манипуляции с nobody рутом обходятся легко и непринуждённо. Если вы рут, то вы можете с лёгкостью войти под любым именем, без всяких паролей. А если это ВАШ компьютер, то вы == рут.

Прекрасно.
Тогда к Вам вопрос.
Нам доступна целая куча всяких дистров линукса, в них из коробки "по-бытовому", т.е. стартует от рута.

Так вот это

вот в том-то и дело, что программа авторизации запущена "от имени" некоего "no body", т.е. абсолютно бесправного и бестелесного юзера, у которого нет НИЧЕГО.

из теории или из практики? Вам встречались системы, где сделано не "по-бытовому"?

[SLEDopit]

Патрик не осилил pwgen и написал свой велосипед?

Да этих генераторов в одном только дебиановском репозитории с десяток

Код: Выделить всё

i   apg                         - Automated Password Generator - Standalone version
p   fpm2                        - password manager with GTK+ 2.x GUI
p   funcoeszz                   - script with 65 useful mini applications
p   gpw                         - Trigraph Password Generator
p   libstring-mkpasswd-perl     - Perl module implementing a random password generator
p   otp                         - Generator for One Time Pads or Passwords
p   passwdqc                    - password strength checking and policy enforcement toolset
p   password-gorilla            - cross-platform password manager
p   pwgen                       - Automatic Password generation
p   xul-ext-pwdhash             - per-site password generator for Mozilla browsers

А уж сколько их за его пределами..

[drBatty]

Я его не рекомендовал.

я видел. Однако вы не понимали, почему я был против такой рекомендации. Надеюсь, теперь понимаете.

Подпись? Зачем ещё подпись?

как же без подписи?! Без подписи существует риск подмены: враг может зашифровать какой-то пароль не туда, а вы и пойдёте как послушный телок в это "не туда". А у же в этом "не там" вы (а скорее ваш послушный браузер/другая программа) введёт всё остальное. Потому, когда вы войдёте туда, куда надо, то увидите лишь голые стены, тлен и запустение. В лучшем случае. В худшем -- увидите железную дверь, за которой живут совсем другие люди, которые тут совсем не при чём.

Патрик не осилил pwgen и написал свой велосипед?

угу. Этот велосипед от Патрега намного более удобнее вашего велосипеда. Т.к. с круглыми колёсами и без крыши. (:

Это Вы передёргиваете. Я про keepass вообще ни слова не говорил (а также никогда им не пользовался, только название слышал - вот оно зачётное, да).

программа тоже была хорошей, пока не скатилась в СГ. Это я так, для примера. Остальное УГ всегда было УГ, т.ч. ещё хуже (:

[drBatty]

из теории или из практики? Вам встречались системы, где сделано не "по-бытовому"?

это из практики. Просто это несколько другая практика: так делают авторизацию удалённого доступа. А для локального это имеет мало смысла. Потому, вообще говоря, локально можно было-бы хранить пароль ОДНОГО юзера и в текстовом файле.

Это просто неудобно -- этот юзер будет рутом(иначе, зачем он нужен?), а под рутом работать неудобно, ибо очень просто случайно что-нибудь испортить.

[drBatty]

вот здесь подробнее напишу: создание бекапов домашнего компьютера

[NickLion]

Да этих генераторов в одном только дебиановском репозитории с десяток

Код: Выделить всё

p   pwgen                       - Automatic Password generation

Поставил, посмотрел. Он даже спецсимволы не включает. Они все такие? Пользовался своим "изобретением":
dd if=/dev/random of=/dev/stdout bs=1 count=50 2>/dev/null | perl -e '@s=$ARGV[0] eq "a" ? () : (split//," !\@#\$%^&*()_+-=~/\\?.,<>[]{};:|"); @s=(a..z,A..Z,0..9,@s); $p=""; while(read STDIN,$x,1) {$p .= $s[ord($x)%scalar @s];}; print "$p\n"'
Вместо 50 — длина пароля. Если в конец добавить 'a', то будут использоваться только буквы и цифры.

[drBatty]

Он даже спецсимволы не включает. Они все такие?

обычно это опционально регулируется. У меня -- включает некоторые(который от Патрега).

Пользовался своим "изобретением":

я ещё не видел администратора, который бы не изобрёл свой генератор паролей...

[Bizdelnick]

Однако вы не понимали, почему я был против такой рекомендации. Надеюсь, теперь понимаете.

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

как же без подписи?! Без подписи существует риск подмены: враг может зашифровать какой-то пароль не туда, а вы и пойдёте как послушный телок в это "не туда".

С какой это стати я попрусь неведомо куда? Допустим, мне надо на paypal.com. Если у меня в менеджере паролей (не важно, каком) будет прописан некий paupa1.com, я же не стану эту белиберду в адресную строку браузера вставлять. Да и даже если там будет paypal.com - не буду копировать, просто потому что это неудобно.

А у же в этом "не там" вы (а скорее ваш послушный браузер/другая программа) введёт всё остальное.

Опять - с какой стати? Браузер может подставить учётные данные в форму ввода, но сам её никогда не отправляет. Остальные программы и подставить ничего не могут.

[NickLion]

Он даже спецсимволы не включает. Они все такие?

обычно это опционально регулируется. У меня -- включает некоторые(который от Патрега).

man я глянул, не было опций.