アカウント名:
パスワード:
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。パスワード認証だろうと通信自体は暗号化されるし、なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。 つまり、ブルートフォースアタックに弱いだけですので、「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。 多くの組織の場合、パスワードの前半部
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
中間経路でのなりすまし攻撃に対して公開鍵認証と比べたらパスワード認証の方が弱いというのは事実でしょう。
なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
まともな運用が出来ていればいいのですが、『日本の運用』を考えた場合、「取り合えずyesと入力しろ」とか「訊かれたくなければStrictHostKeyChecking=noに設定しろ」等の情報が氾濫している現状から、あまり考えもせずにyesを入力するケースも有りそうです。実際、Tera Termにも「警告を抑制できるようにして欲しい」という要望が多く来たのに負けて /nosecuritywarning [ttssh2.osdn.jp] を追加してしまいましたし。# 実際には海外からも要望が来ていたので日本に限ったものではないかもしれませんが
そしてホスト鍵の確認が不十分な時はパスワード認証は脆弱で、中間者攻撃が行われている場合は接続先が本物のホストだった(ように見えた)時でも安全ではありません。一方、公開鍵認証は(認証に関しては)安全ですし、本物のホストのホスト鍵が変わったのか、それとも中間者攻撃が行われているかの判別も可能です。(中間者攻撃の場合は認証が失敗する)
「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
14文字ありますが
など、かなり使われている文字に偏りが有りますね。それらをおまけして"英大文字"/"小文字"/"数字"/"記号"の四種類、計95文字の中から14文字と考えると92bit程度の強度ですね。これはRSA 1024bit鍵の80bit相当よりは安全ですが、現在主流のRSA 2048bit鍵の112bit相当やED25519鍵の128bit相当よりはかなり落ちます。# 最新のOpenSSHではRSA鍵はデフォルトで3072bit(128bit相当)を生成するように変わりました
また、このパスワードは「英大文字/小文字/数字4桁を3つ作り、それを : で繋げる」というルールで作られているようにも見えます。この場合は72bit程度の強度になるので、今はもう使うなと言われているRSA 1024bit鍵よりも弱い事になります。# まあそれでもオンラインでのブルートフォース攻撃だけを想定するならば十分ではありますが
秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。
秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。
他のコメントでも指摘されていますが、OpenSSH標準で秘密鍵は暗号化されますし、パスフレーズを付けて保護されるのが一般的です。一般的には行われていない運用を仮定してそれをもって公開鍵認証の方が脆弱だとするのは不公平な比較でしょう。前述したパスワード認証の問題も評価出来ていませんし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
日本の運用だとかえって危険になる気がする (スコア:0)
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
パスワード認証だろうと通信自体は暗号化されるし、なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
つまり、ブルートフォースアタックに弱いだけですので、「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
多くの組織の場合、パスワードの前半部
Re:日本の運用だとかえって危険になる気がする (スコア:2)
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
中間経路でのなりすまし攻撃に対して公開鍵認証と比べたらパスワード認証の方が弱いというのは事実でしょう。
なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
まともな運用が出来ていればいいのですが、『日本の運用』を考えた場合、「取り合えずyesと入力しろ」とか「訊かれたくなければStrictHostKeyChecking=noに設定しろ」等の情報が氾濫している現状から、あまり考えもせずにyesを入力するケースも有りそうです。
実際、Tera Termにも「警告を抑制できるようにして欲しい」という要望が多く来たのに負けて /nosecuritywarning [ttssh2.osdn.jp] を追加してしまいましたし。
# 実際には海外からも要望が来ていたので日本に限ったものではないかもしれませんが
そしてホスト鍵の確認が不十分な時はパスワード認証は脆弱で、中間者攻撃が行われている場合は接続先が本物のホストだった(ように見えた)時でも安全ではありません。
一方、公開鍵認証は(認証に関しては)安全ですし、本物のホストのホスト鍵が変わったのか、それとも中間者攻撃が行われているかの判別も可能です。(中間者攻撃の場合は認証が失敗する)
「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
14文字ありますが
など、かなり使われている文字に偏りが有りますね。
それらをおまけして"英大文字"/"小文字"/"数字"/"記号"の四種類、計95文字の中から14文字と考えると92bit程度の強度ですね。
これはRSA 1024bit鍵の80bit相当よりは安全ですが、現在主流のRSA 2048bit鍵の112bit相当やED25519鍵の128bit相当よりはかなり落ちます。
# 最新のOpenSSHではRSA鍵はデフォルトで3072bit(128bit相当)を生成するように変わりました
また、このパスワードは「英大文字/小文字/数字4桁を3つ作り、それを : で繋げる」というルールで作られているようにも見えます。
この場合は72bit程度の強度になるので、今はもう使うなと言われているRSA 1024bit鍵よりも弱い事になります。
# まあそれでもオンラインでのブルートフォース攻撃だけを想定するならば十分ではありますが
秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。
秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。
他のコメントでも指摘されていますが、OpenSSH標準で秘密鍵は暗号化されますし、パスフレーズを付けて保護されるのが一般的です。
一般的には行われていない運用を仮定してそれをもって公開鍵認証の方が脆弱だとするのは不公平な比較でしょう。前述したパスワード認証の問題も評価出来ていませんし。