Причина, по которой это НЕ делается, легко обнаруживается, если посмотреть, что может произойти на сайте, где это делается.
Однажды мне потребовалось улучшить хэш-пароль на сайте, который регистрировал плохие пароли (по какой причине они это делали, я не могу представить). Чтобы свести к минимуму неудобства пользователей, я сначала сделал автоматическую конвертацию пользователей по мере их входа в систему, но поскольку те, кто не входил в систему некоторое время, также нуждались в улучшенной защите, я попробовал взломать их, конвертируя все угаданные пароли в более высокий стандарт хэширования.
После недели перебора всего, что я знал: списки известных паролей из крупных утечек, таких как facebook, словари многих языков, перестановки и так далее, у меня осталось около 4 000 паролей людей, которые не вошли в систему, и которые я не смог взломать.
Я взял журнал плохих паролей за последние несколько лет, использовал эти пароли против невзламываемых паролей и взломал четверть оставшихся. То есть он угадал четверть действительно сложных паролей в системе, включая несколько учетных записей администраторов, и это означает, что мне нужно было сбросить пароли только 3 000 пользователей, а не 4 000.
Поэтому я считаю, что ценность такого журнала для злоумышленника невозможно переоценить.
Просто нет веских причин для регистрации неудачных паролей, и есть все причины избегать этого - в случае утечки этих данных вы раскрываете информацию о входе для большого числа пользователей. Эти "неудачные пароли" будут паролями, которые они сменили, или которые они используют для других учетных записей в вашей системе, или которые они используют в других системах (их банк, их электронная почта...)
Сохраняя такой журнал, вы подвергаете опасности своих пользователей без реального преимущества в безопасности.
man 5 utmp дает хороший ответ:
The utmp file allows one to discover information about who is currently using the system.
The wtmp file records all logins and logouts.
Да, он содержит информацию о выходе из системы.
Когда сеанс интерактивного входа в TUI завершается, в эту таблицу вводится запись DEAD_PROCESS
, заменяющая предыдущую USER_PROCESS
. Эта запись не живет долго (в некоторых системах, по крайней мере ), так как управление службой входа в систему терминала вскоре повторно использует службу входа в систему, перезаписывая запись DEAD_PROCESS
новой GETTY_PROCESS
или LOGIN_PROCESS
. Но там его можно найти.
В других системах, где нет таких вещей, как запись GETTY_PROCESS
или LOGIN_PROCESS
, она живет несколько дольше, и с ней легче столкнуться. Тем не менее, это трудно увидеть без программного доступа к таблице, так как утилиты обычно отфильтровывают DEAD_PROCESS
записи при печати содержимого таблицы.
Кроме того, :из-за ошибок в этой таблице будут DEAD_PROCESS
записи для сеансов входа в систему с графическим интерфейсом из некоторых современных сред рабочего стола без ограничений.
pututxline
. Базовые характеристики . IEEE 1003.1 :2017. Открытая группа.