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

すでにログイン名を入力したと思ったため、キーボードを見下ろしてパスワードを入力しました。を押したEnter後、パスワードを要求されたときにCtrl+ を押しましたc。

パスワードがプレーンテキストでどこかに保存されていないことを確認するための予防措置を講じる必要がありますか、それともパスワードを変更する必要がありますか？

また、これはubuntuサーバー16.04 LTS上のttyにありました。

security login password

— ヘルマンカイン
ソース

パスワードはログファイルに含まれるので、パスワードを含めないように編集する必要がありますが、ログファイルからパスワードを削除した後でも、万が一に備えてパスワードを変更することをお勧めします。

— ジョンミリター

セキュリティseの複製：security.stackexchange.com/questions/101172/…–

— stanri

別のPCからSSH +公開キーを使用し、緊急時にのみコンソールディスプレイとキーボードを使用するもう1つの正当な理由。

— RedGrittyBrick

@staceyは、Qが他のユーザーによって制御される（おそらくリモートの）サイトへのログイン用であること。これはローカルシステム用です。オーバーラップはありますが、同じではありません。

— -dave_thompson_085

これをテストするUbuntu 16.04システムはまだありません。ただし、Ubuntu 14.04デスクトップインストールでまったく同じ手順を実行しても、ユーザー名またはパスワードは記録されません。パスワードがログファイルに記録されるのを防ぐために、適切なタイミングでctrl-cを押したようです。

— カスペルド

回答:

101

問題は、パスワードが認証ログに記録されているかどうかです。

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

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

認証ログを確認して確認できます。Ubuntu 14.04またはSysVinitを使用したDebian jessieでは、認証ログはにあり/var/log/auth.logます。

これが排他的な制御下にあるマシンであり、リモートでログを記録せず、ログファイルがまだバックアップされておらず、何も壊さずにログファイルを編集できる場合は、ログを編集しますパスワードを削除するファイル。

パスワードがシステムログに記録されている場合は、パスワードが危険にさらされていると考えて、変更する必要があります。ログは、バックアップ、支援のリクエストなど、あらゆる種類の理由でリークする可能性があります。たとえあなたがこのマシンの唯一のユーザーであっても、リスクを冒さないでください。

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

— ジル
ソース

後者の場合、再利用したすべての場所で変更する必要があります。

— グロノスタジュ

間違っている場合は修正してください。ただし、これらのログが表示されるのは通常、必要に応じて既にデータにアクセスできる人だけです。では、パスワードが表示されたらどうしますか？大したことは何ですか？

— Mehrdad

@Mehrdad認証ログは通常、管理者専用です、true。しかし、キーロガーをインストールする能力を持つ誰かを信頼することと、私のパスワードでそれらを信頼することには違いがあります。また、バックアップがリークしたり、トラブルシューティングを支援するために誰かとログを共有したりする可能性もあります。ログエントリがリークするリスクは無視できないほど高いです。

— ジル

この答えが正しければ、それはUbuntu 14.04と比較した回帰です。Ubuntu 14.04で上記の手順を実行しても、ユーザー名またはパスワードは記録されません。これは、情報が記録される前にctrl-cを押すことでログインが中断されたためです。

— カスペルド

@kasperd回答として投稿します。

— wizzwizz4

あなたの場合、あなたは安全です-パスワードを入力し、それをキャンセルしました。ログインプロンプトに入力したパスワードに続いて間違ったパスワードを入力すると、認証に失敗したと見なされ、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)

それについて何か良いことはありますか？まあ。。攻撃者は、そもそもシステムにアクセスする必要がありbtmpます。さらに、ログを読み取るには、rootアクセスが必要です。これはまた、単一のユーザーコンピューターにとっても意味します。これは、パスワードが既に盗まれているのと同等であり、攻撃者がパスワードを知っていれば、攻撃者にとってはまったく役に立ちません。エントリ内のパスワードは、すでに推測できますが、部分的にしか記録されていませんが、攻撃者にとってはかなり公平な利点があるため、その部分については何も良いことはありません

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

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

— セルギ・コロディアズニー
ソース

また、誰かが同じマシンでライブOSを起動する場合、このプレーンテキストファイルのログファイルにパスワードが表示されることも事実です。この同じパスワードを他の場所で使用すると、別のセキュリティリスクが生じる可能性があります。ログファイルからそれらをフラッシュし、このパスワードの重要性に応じて空き領域を上書きするプログラムを使用することをお勧めします

— ジョー

@Joe私たちが話している特定のログは？/var/log/auth.log？ええ、パスワードの再利用はよくある問題です。私はそれをよく知っているので、何も再利用しません。

— セルギーコロディアズニー

私が知っているように、すべてを1つのパスワードで管理している人が多いので、他の人がこれを調べたときも同様に考えました。

— ジョー

また、btmpファイルも上書きする必要があります

— ジョー

結論として..単純にsudo rm /var/log/btmp？

— phil294