Как сделать так, чтобы пароли пользователей отображались как открытый текст в Linux?

Мы знаем, что пароли пользователей сохраняются /etc/passwd, но в зашифрованном виде, поэтому даже root не может их увидеть:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

Как показано выше, :x:представляет собой пароль.

Есть ли способ (возможная конфигурация) сохранить пароль /etc/passwdв виде открытого текста и чтобы рут мог их видеть?

Два других ответа сказали вам - правильно! - что это плохая идея ™ . Но они также сказали вам, что это трудно сделать, требуя изменения нескольких программ.

Это не правда. Это очень просто. Вам нужно всего лишь изменить один или два файла конфигурации. Мне важно отметить это, потому что вы должны знать об этом при входе в системы, которые вы не контролируете. На самом деле они не будут вводить простой текстовый пароль, /etc/passwdили /etc/shadowперейдут в другой файл. Обратите внимание, что я не проверял их, так как я бы предпочел, чтобы мой пароль не отображался в текстовом виде

1. Изменить /etc/pam.d/common-password(чтобы поймать на измененный пароль) или /etc/pam.d/common-auth(чтобы поймать при входе в систему) и добавить в… pam_exec expose_authtok log=/root/passwords /bin/cat

2. Отредактируйте оба из них и переключитесь с pam_unix на pam_userdb с помощью crypt=none. В качестве альтернативы, вы можете поместить его только в общий пароль (оставляя также pam_unix), чтобы просто записывать пароли при их изменении.

3. Вы можете удалить shadow(а также любые сильные параметры хеширования) из pam_unix, чтобы отключить теневой файл и вернуться к традиционным паролям шифрования. Не простой текст, но Джон Потрошитель это исправит.

Для получения дополнительной информации обратитесь к Руководству системного администратора PAM .

Вы также можете отредактировать исходный код PAM или написать свой собственный модуль. Вам нужно только скомпилировать PAM (или ваш модуль), ничего больше.

О дорогой, хорошо, давайте начнем с самого начала ...

Мы знаем, что пароли пользователей сохраняются в / etc / passwd, но в зашифрованном виде.

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

но в зашифрованном виде, поэтому даже root не может их увидеть:

Я знаю , что иногда используются как синонимы, но хэширования не шифрование . Шифрование по своему определению является обратимым, то есть вы можете перевести зашифрованную вещь обратно в форму открытого текста. Хэш предназначен для не обратимы каким - либо образом (кроме грубой силы). Оригинальная открытая форма чего-то, что хэшируется, не подлежит восстановлению.

Пароли в теневом файле хранятся в виде хэшей.

как показано выше: x: представляет пароль

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

Есть ли способ (возможная конфигурация) сохранить пароль в / etc / passwd в виде обычного текста, чтобы root мог их увидеть?

Да, это действительно возможно, но по некоторым причинам это не очень хорошая идея. Ответ Дерберта объясняет довольно простой способ сделать это .

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

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

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

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

Прежде всего, зашифрованные пароли не в /etc/passwd, но они в /etc/shadow. Одна из причин этого заключается в том, что она /etc/passwdявляется общедоступной (например, вы можете найти информацию о полях GECOS для другого пользователя), и, особенно с более старыми схемами шифрования, может разрешить атаки методом "грубой силы" против зашифрованного пароля.

Хранить пароли в виде простого текста не нужно, и для этого потребуется обновить программу паролей и библиотеки, читающие /etc/shadow информацию для проверки правильности паролей. И затем вы должны надеяться, что все утилиты используют общие библиотеки для доступа к этой информации вместо того, чтобы быть статически связанными с чем-то, что не понимает хранение паролей в виде простого текста.

Если это будет вариант в конфигурации установки, то всегда найдутся глупые люди, которые включат его ненадлежащим образом. И хотя они все еще работают на экранах ЭЛТ и транслируют это таким образом, чтобы их можно было легко найти снаружи их здания, пока они смотрят на информацию.

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

Там должно быть более интересные вещи, работа может быть исследована в вашей системе.

Основная причина (почему это плохая идея) заключается в том, что ни один пользователь (root, admin или другой) никогда не должен иметь доступ к паролю другого пользователя.

Просто потому, что пароль является средством аутентификации. Если я знаю пароль другого пользователя, я знаю его учетные данные (имя пользователя + пароль), поэтому я могу войти в систему под этим пользователем , выдавая себя за него (или ее, или ее).

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

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

Или просто незаконно. Представьте себе банковское учреждение, где у меня (администратора) есть доступ ко всем паролям. Используя пароль кассира, я могу заказать перевод миллиона долларов с банковского счета президента на банковский счет мойщика окон. Затем используйте пароль кассира для подтверждения транзакции. Затем утвердите чек со счета мойщика окон на мой собственный счет в оффшорном банке.

Тогда я уезжаю на долгие каникулы на Багамы ...

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

И, как прокомментировал @ Miral ^* , есть исключениеsu которое, хотя и разрешает олицетворение (и виды приведенного выше аргумента), также ведет журнал его использования (поэтому оно меняет правила на «только администраторы могут выдавать себя за других, но журнал хранится ").

^{* Пример банка был, вероятно, не лучшим. В любой среде, где безопасность имеет решающее значение, обычно требуется больше средств аутентификации и авторизации, чем один пароль.}