Як зробити паролі користувачів відображеними як чіткий текст у 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. Відредагуйте обидва з них та перейдіть з пам_унікс на пам_ужордб crypt=none. Крім того, ви можете вводити його лише у загальний пароль (залишаючи пам’ятник також), щоб просто записувати паролі, коли вони змінюються.

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

Для отримання додаткової інформації перегляньте посібник адміністратора системи PAM .

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

О, дорогий, добре, почнемо з самого початку ...

Ми знаємо, що паролі користувачів зберігаються в / etc / passwd, але зашифрованим способом

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

але зашифрованим способом, тому навіть корінь не може їх побачити:

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

Паролі у тіньовому файлі зберігаються як хеші.

як показано вище: x: представляють пароль

У xцьому випадку це лише заповнювач застарілого поля пароля. Це xозначає, що пароль можна знайти в тіньовому файлі.

Чи існує спосіб (можлива конфігурація) зберегти пароль у / etc / passwd у чистому тексті та таким, щоб корінь міг їх бачити?

Так, це дійсно можливо, але це не є хорошою ідеєю з якихось причин. Відповідь Дероберта пояснює досить простий спосіб зробити це .

Але чому це не гарна ідея? Ну, з простої, але дуже важливої ​​причини: безпека. Я пропоную прочитати ці питання:

• Яка хороша аналогія, щоб пояснити, чому паролі потрібно хеширувати непрофесійним?
• Як послідовно виконувати хеш-паролі?
• Чому я повинен хеш-паролі?
• Чому хешування паролів вважається таким важливим?
• Чому хеш-функції є одним із способів? Якщо я знаю алгоритм, чому я не можу розрахувати вхід з нього?

Але підводячи підсумок, припустимо наступне: У компанії є сервер, усі облікові записи користувачів захищені своїми паролями, а дані в цих облікових записах користувачів шифруються одним і тим же паролем. Зловмисник ззовні отримує доступ до сервера, але вони не можуть отримати доступ до жодної важливої ​​інформації, оскільки це все ще зашифровано в облікових записах користувачів.

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

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

Щоб просто зберігати паролі в простому тексті, не потрібно, і знадобиться оновлення програми паролів і бібліотек, що читають /etc/shadow інформацію, щоб перевірити чи справжні паролі. І тоді ви повинні сподіватися, що всі утиліти використовують спільні бібліотеки для доступу до цієї інформації, а не статично пов’язані з тим, що не розуміє простого зберігання текстового пароля.

Якщо це було б варіантом у конфігурації налаштування, то завжди були б дурні люди, які вмикали б його неналежним чином. І хоча вони досі працюють на екранах CRT і транслюють це таким чином, що його можна легко забрати поза їхньої будівлі, поки вони переглядають інформацію.

Крім цього, люди, як правило, використовують один і той же або подібний пароль у кількох системах, так що не є доброю ідеєю для того, щоб будь-які паролі були зрозумілими для людини. Оскільки деякі sysadmin можуть спробувати їх в інших системах, він знає, що у користувача є обліковий запис.

Повинно бути більше цікавих речей, роботу яких можна дослідити у вашій системі.

Основна причина (чому це погана ідея) полягає в тому, що жоден користувач (root, адміністратор чи інший) ніколи не повинен мати доступ до пароля іншого користувача.

Просто тому, що пароль - це засіб аутентифікації. Якщо я знаю пароль іншого користувача, я знаю їхні облікові дані (ім’я користувача + пароль), тому я можу ввійти як цей користувач , видаючи себе за нього (або її чи ні).

За будь-яку дію, яку я вчинив, коли ввійшов як цей користувач, за іншого користувача несе відповідальність. І це не так, як повинна працювати автентифікація.

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

Або просто незаконне. Уявіть банківську установу, де я (адміністратор) має доступ до всіх паролів. Використовуючи пароль касира, я можу замовити переміщення мільйона доларів з банківського рахунку президента на банківський рахунок прибиральника вікон. Тоді використовуйте головний пароль касира, щоб затвердити транзакцію. Потім затвердіть чек з рахунку очисника вікон на мій власний офшорний банківський рахунок.

Потім я вирушаю на довгі канікули на Багами ...

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

І як прокоментував @ Miral ^* , виняток є тим, suщо, дозволяючи себе за себе (і види відкидання аргументу, наведеного вище), він також веде журнал його використання (тому він змінює правила на "лише адміністратори можуть себе представляти іншим, але журнал зберігається ").

^{* Приклад банку, мабуть, не найкращий. У будь-якому середовищі, де безпека є вирішальною, зазвичай потрібно більше засобів аутентифікації та авторизації, ніж лише один пароль.}