☰

誤ってログインフィールドにパスワードを入力しましたが、それでも安全ですか？

tag-icon • tag-icon security login password
誤ってログインフィールドにパスワードを入力しましたが、それでも安全ですか？

私はすでにログイン情報を入力していると思い、キーボードを見下ろしてパスワードを入力しました。を押してEnterパスワードの入力を求められたら、Ctrl+を押しましたc。

パスワードがプレーンテキストでどこかに保存されないように予防策を講じる必要がありますか、パスワードを変更する必要がありますか？

これはUbuntu Server 16.04 LTSのttyでも行われました。

答え1

注意すべき点は、パスワードが認証ログに書き込まれるかどうかです。

もしLinuxでテキストコンソールにログインしていますCtrl+を押しました。Cパスワードプロンプトが発生した場合、ログエントリは生成されません。少なくともこれはSysVinitを含むUbuntu 14.04またはDebian jessie、おそらく他のLinuxディストリビューションでも同じです。 Systemdを使用しているシステムでは、これがまだ発生していることを確認していません。 +を押すと、Ctrlログエントリが作成される前にCプロセスが終了します。loginだからあなたは安全です。

一方、ログインしようとした場合（パスワードプロンプトでEnterまたは+を押すと）、入力したユーザー名が認証ログにプレーンテキストとして表示されます。失敗したログインはすべて記録されます。ログエントリにはアカウント名が含まれていますが、パスワードに関する情報は含まれていません（パスワードは正しくありません）。CtrlD

これは認証ログで確認できます。 SysVinitを含むUbuntu 14.04またはDebian jessieの認証ログは/var/log/auth.log。

このコンピュータがあなたが排他的に制御し、リモートでログを記録せず、ログファイルがバックアップされておらず、何も損なうことなくログファイルを編集できる場合は、ログファイルを編集してパスワードを入力してください。

パスワードがシステムログに記録されている場合は、そのパスワードが破損していると想定してパスワードを変更する必要があります。バックアップ、ヘルプリクエストなど、さまざまな理由でログが漏洩する可能性があります。このコンピュータの唯一のユーザーでさえ危険を避けてください。

注：Ubuntu 16.04が動作が異なることを確認していません。この回答はすべてのUnixバリアントに一般化されるわけではなく、すべてのログイン方法に適用されるわけではありません。たとえば、OpenSSH はパスワードプロンプトでCtrl+ を押してもC（実際にはパスワードプロンプトが表示される前に）ユーザー名を記録します。

答え2

あなたは安全です。パスワードを入力してキャンセルしました。ログインプロンプトでパスワードを入力した後に無効なパスワードを入力すると、認証失敗として処理され、部分的に記録されますbtmp。コンソールの場合はtty大丈夫です。

$ sudo lastb                                                                   
[sudo] password for xieerqi: 
UNKNOWN  tty1                          Mon Apr 25 22:14 - 22:14  (00:00)

「誤って」入力したパスワードは記録されるため、UNKNOWNここではすべてが正常です。ただし、GUIログイン画面の失敗した認証には、難読化されていない失敗したログインエントリが表示されます。

$ sudo lastb                                                                   
[sudo] password for xieerqi: 
hellowor :1           :1               Mon Apr 25 22:17 - 22:17  (00:00)    
UNKNOWN  tty1                          Mon Apr 25 22:14 - 22:14  (00:00)

これにはどんな利点がありますか？素晴らしい。 。攻撃者は最初にシステムにアクセスできる必要があり、さらに重要なのは、ログを読むにはrootアクセス権が必要ですbtmp。これがシングルユーザーのコンピュータにとって何を意味するのかは、あなたのパスワードが盗まれたのと同じです。アイテムのパスワードが部分的にのみ記録されていることはすでに推測できますが、これは攻撃者に大きな利点を提供するため、その部分はほとんど利益になりません。

パスワードを変更する必要がありますか？おそらく100％確信するためです。一方、攻撃者はbtmpログにアクセスできる必要があり、これは.logにアクセスするのと同じであり、/etc/shadow実質的な利点はありません。

サイドノート：私のUbuntu 14.04のすべての出力

答え3

私の考えでは@ギルズの答え大きい。しかし、私は彼の技術的なポイントを見せることによってこの点を強調したいと思います。

  1. テキスト/コンソール（つまり、GUIではない）を介してログインしている場合...
  2. 特定のディストリビューションを使用している場合...
  3. systemdの代わりにsysvinitがある場合...
  4. ctrl-cを押すと...
  5. ログインしようとしている場合（ctrl-dまたはEnterを押す）...
  6. 認証ロギングを有効にすると...
  7. コンピュータがオフラインでコンピュータにアクセスできる唯一の人であれば...
  8. マシンがリモートでログ認証用に設定されている場合...
  9. マシンがバックアップを持つように構成されている場合...
  10. マシンのスケジュールされたバックアップが実行されている場合...
  11. ログファイルを編集する方法を知っていて、以前のバージョンが何らかの方法で保存されていないことを確認したら...
  12. sshでログインすると...

これは、問題が発生する可能性がある場所が12個（おそらく12個以上）であることを意味します。パスワードを変更することは、12の場所をすべて徹底的に確認するよりも少なくとも10倍は速いと思います[1]。また、パスワードを変更すると心の平和を得ることができます（おそらくパスワードを徹底的に確認しましたが、何かを逃したかもしれません）。

[1] そして、正しく確認してください（例：ログの検索、バックアップ計画の検索、リモートロギングの仕組みの探索、私が持っている distro/systemd バージョンの調査、対応する distro/systemd バージョンでの認証ロギングのしくみの調査）。 ）私たちの会社のロギングの実装は何であり、私たちの会社のバックアップの実装は何であるかを調べてください。）

PS最後に1つだけ申し上げます。適切に管理されているLinuxボックス（企業、教育機関、クラウドなど）を使用する場合は、次のいずれか1つ以上が適用されます。だから必ずパスワードを変えるように申し上げたいです。

関連情報