記号から始まるパスワードによる誤動作リスク 97
ストーリー by nagazou
リスク 部門より
リスク 部門より
少し前にユーザー名を数字で登録するとバグが発生するという話題を紹介したことがあったが、似たようなことがパスワードでも発生しているようだ。＠mainyさんの「Qiita」上の記事によれば、パスワードの1文字目に「~(チルダ)」を使用すると問題があるのだという。同氏によると踏み台サーバー経由でサーバーAに接続して作業をし、サーバーA上でroot権限になろうと「sudo su -」し、上記の「~.xxxxxxxxxx」のような「~」から始まる条件のパスワードを入力したらサーバーAから追い出されてしまったという（＠mainyさんの記事）。
結論としては「~.」 は ssh 接続を閉じるコマンドであり、パスワードを入力しているつもりなのに、2文字目の . を入力した途端 ssh がサーバーAの接続を閉じて踏み台サーバーに戻るという現象が発生、結果としてパスワード入力中に接続が閉じられるという状況になってしまったという。なおパスワードの途中に「~.」があっても問題は無いそうだ。
結論としては「~.」 は ssh 接続を閉じるコマンドであり、パスワードを入力しているつもりなのに、2文字目の . を入力した途端 ssh がサーバーAの接続を閉じて踏み台サーバーに戻るという現象が発生、結果としてパスワード入力中に接続が閉じられるという状況になってしまったという。なおパスワードの途中に「~.」があっても問題は無いそうだ。
パスワードの途中に「~.」があっても問題は無い (スコア:3, 興味深い)
こういう説明をするからだめなんだよ。
改行の直後でのみエスケープ文字は有効、て理解しなきゃ。
RTFM
The escape character must always follow a newline to be interpreted as special.
Re:パスワードの途中に「~.」があっても問題は無い (スコア:2)
正しくは「改行の直後」じゃなくて「行の先頭」だと思います．
例えば，接続直後なら "~." って打つだけで切断されます．改行は不要です．
openssh のman page (ネット上で見るならhttps://man.openbsd.org/ssh)を確認すると
確かに
と書いてあります．しかしよく読むと以下の記述もあります
たぶん前者の記述は間違っています．newlineがなくても良い場合があるからmustではありません．
後者の記述のほうがより正しい説明だと思われます．
Re:パスワードの途中に「~.」があっても問題は無い (スコア:1)
いや、そもそもsshが解釈している「キーボードの入力」と、表示されている「行」とは一対一対応するものでもないので、行の先頭というのもそれはそれで不正確ですよ。
今回のケースでも「password:」と表示されているところに入力する形になるから、「行の先頭」じゃないですし。
正確を期すなら、「接続直後 または 改行を送信した直後」といったところでしょう。
Re: (スコア:0)
特定個人の意図と反する動作したら誤動作と言われたりするからな
仕様通りなんだわ
Re:パスワードの途中に「~.」があっても問題は無い (スコア:3, 参考になる)
仕様知らないやつが変なこと言ってるだけのパターンだな。
ssh にも記号のパスワードにも何の問題もない。
改行の直後に ~ を打つと ssh の制御コードになるのはまっとうな仕様。
作業中に固まったら return ~. って打って強制切断とか普段から良く使うだろ。(文句言うやつは使ってないんだろうな)
~. で切断の他にも ~B でブレークの送信とか必要になることもある。(~C で port forward 用のメニューとかも便利)
改行の直後に ~ を入れたい場合には ~~ と2回打てば良い。(ssh を2段踏んでれば ~~~ と3回入れる。3段なら4回)
Re:パスワードの途中に「~.」があっても問題は無い (スコア:2, 参考になる)
Secure Shellプロトコルで決まってるわけじゃないが、
「~」をこのように使うのは OpenSSH だけじゃなくて
Tatu Ylönenによるオリジナルのsshもそうだし、
rlogin も cu も tip もそうなわけで、
UNIX上のCLI型リモートアクセスコマンドではむしろ常識ですよ
Re:パスワードの途中に「~.」があっても問題は無い (スコア:1)
昔の端末は普通の印字可能文字しかキーボードから入力できない可能性があったからでは。viのhjklカーソルもカーソルキーがない端末のためのものだったし
無害な文字をいったん入れて削除するの巻 (スコア:2, 参考になる)
ipmitool sol activateでも同じですが、いったん "a" とかの無害な文字を入れておいてバックスペース(CTRL+H)で消して入れなおす、という技もあったりします。
こんなのバグだろ (スコア:1, おもしろおかしい)
パスワードに記号使われるなんて当然なんだから、入力中は無視するぐらいはしようよ
酷い作りだな
ユーザビリティのかけらもない
Re: こんなのバグだろ (スコア:3)
そういうのはusabilityとは言わない。せめてuserfriendly。できればbeginner-friendlyと呼んでくれ。
Re: こんなのバグだろ (スコア:2)
え、変なパスワードのせいで罠にハマっちゃったテヘペロって話じゃなかったの？修飾キー同時押しなんてbash(じゃなくても良いけど)のショートカットキーを間借りすることになって余計にややこしい。
Re: (スコア:0)
えーと、どれの？
「sshがパスワード入力中か判別できないのが悪い」とでも？
パスワードじゃなくても、行頭でチルダを単独入力したら切れるよね。
そっちも対応せにゃならんの？
Re: (スコア:0)
現在、端末でパスワード受付中です、とサーバが通知してくる仕組みを設えて、sshクライアントがそれを受けてエスケープシーケンスの入力を一次停止して、ってな無駄に複雑な処理になるので無理。
これ、サーバじゃなくて手元のsshクライアントが入力を横取りしてるだけだからな。sshクライアントの設定変更しろ。
サーバが無反応なときにさっさと繋ぎ直しを試行するときにさっと使えて便利→Enter→~→.。
シリアル通信 (スコア:0)
そういえば昔ソフトウェアフローでうっかりハマる人いましたね
Re: (スコア:0)
その点、telnetは^]だったので、普通に使う分には踏まなかったな。
viに乗り換えた今では^]も多用してるけど、telnetを使ってた頃はemacsを主に使ってたし。
Re: (スコア:0)
シリアル通信じゃないけど、昔 rlogin か rsh で他のマシンに入っていて、vi で大文字小文字変換を連続していた、つまり、~... と打ったら logout してしまった、なんたあったな。
踏み台認証結果 (スコア:0)
サクラチルだ
パスワード頭文字に記号は止めとけ (スコア:0)
弊社、パスワード管理台帳をExcelで作成
ジェネレータで作成したランダムパスワード、頭文字が「'」
何も考えず台帳に転記してたので「'」が消えて……
Re:パスワード頭文字に記号は止めとけ (スコア:1)
"+"3文字をパスワードに含めようとして……
#ATH
Re:パスワード頭文字に記号は止めとけ (スコア:1)
ATモデムの場合、+++ でコマンドモードに入りますが、
その前後に1秒の無通信時間が必要ですし、+++は1秒以上間を開けずに送信する必要があります。
(何も送信せずに1秒待つ→「+」送信→1秒以内に「+」送信→1秒以内に「+」送信→1秒待つ、でコマンドモードに入る)
なので、パスワードに+++が入っていても、
キータイプが速いなら前後の無通信時間が入らないのでコマンド判定されないし
キータイプが遅すぎるなら、+と+の間が開いてコマンド判定されなくなるので、
実用上問題にはならないと思います。
Re:パスワード頭文字に記号は止めとけ (スコア:3, 興味深い)
Re: (スコア:0)
そもそもExcelをパスワードマネージャーにするな
Re: (スコア:0)
Excelは一応データベース機能を含有すると称しているのだが。
Re: (スコア:0)
「○○としても使える。ただし一般的な○○と違って以下のような制約が～」なんてよくある話すぎる
ユーザーパスワードを漢字にしている俺は記号が不可欠 (スコア:0)
たとえば日本語キーボードの場合、せめて「;」「,」「.」「/」などのホームポジションの範囲内で打てる記号は通してほしいんだよ。
「パスワードは破られないように、英大小数字を混ぜましょう」と曰うところほど先述の記号を拒否しやがる。
Re: (スコア:0)
それより日本語使わせて欲しい。暗号強度爆上がりなんだけどな。
Re:ユーザーパスワードを漢字にしている俺は記号が不可欠 (スコア:1)
Re: (スコア:0)
それより日本語使わせて欲しい。暗号強度爆上がりなんだけどな。
IMEに変換履歴として残るのをどうリスク評価するか、だなぁ
suだけじゃ、どうしてダメなの？（オフトピ) (スコア:0)
sudo suなんてしなくても、suだけでいいじゃんって思うのだけど、なんでsudoするの？
Re:suだけじゃ、どうしてダメなの？（オフトピ) (スコア:2, 興味深い)
su - はrootのパスワード
sudo su - は自分のパスワードを使います。
共用サーバなどでrootのパスワードは教えたくない、誰がsudoしたかログを残したい、など相応の理由でsudoを使ってるんだと思います。
# でも sudo -s を知らんのか？とは思う
Re:suだけじゃ、どうしてダメなの？（オフトピ) (スコア:1)
誰がsudoしてどんなコマンドを実行したかログを残して欲しいので、
これを見た人はsudo su -やsudo -iを辞めましょう。
Re:suだけじゃ、どうしてダメなの？（オフトピ) (スコア:3)
history -cまでtypoしたのか…
Re: (スコア:0)
なるほど。rootパスを知らないrootになれる人限定って事ね
モヤモヤしていたんだけど、むしろsudo -sすればいいじゃんって方でスッキリしました。
sudo suってコマンドの並びに「使った事がない」って違和感の方が大きかったです。
Re: (スコア:0)
su - に相当するのは、sudo -i の方だね。
Re:suだけじゃ、どうしてダメなの？（オフトピ) (スコア:2)
他の例 (スコア:0)
openssl s_clientではRとQに特殊な意味が割り当てられているので、SMTPSの動作テストのためにメールサーバにs_clientで接続してRCPT TO:とかQUITとかのコマンドを入れるとおかしなことになったりする。
接続に使うツールじゃなくて接続を受ける側の端末自体で発生する事象だと、vt100じゃない昔の端末では行削除がCTRL-Uじゃなくて@になってるものがあった。こういう端末でメールアドレスを入力したり@を含むパスワードを入力するにはどうすればいいのかは忘れた(sttyしかない?)。
Re: (スコア:0)
普通に \@ としてたけど
みんな-e noneつけないの？ (スコア:0)
SSH 先でIPMIシリアルコンソール使っているとき、シリアルコンソール終了のつもりで~.を入れたらSSHごと切られてしまって「？？」となってから、必ず-e noneつけてSSHするようになりましたよ。
Re: (スコア:0)
昔のRHELはsshのlogoutが貧弱で強制切断は必須だった。
最近のは問題ないようだけど、念の為ということで普通に ~ を escape_char にしてる。
linux系はセキュリティ低すぎ (スコア:0)
コマンドラインはコマンドとデータが分離してないからこんなことになる。そんなコマンドラインでなんでもやろうとするからそうなる。
分離した仕組みが必要だよ・・・
＃一応標準入力で分離できるけどいまいち
逆にセキュアになる・・・ (スコア:0)
ssh踏み台経由の root login を禁止するために、あえて ~. で始まるパスワードにしてたけど。
当然、su - もできなくなるけど、sudo -i でいいと思ったから。
苦情が多くて結局やめた。
Re: (スコア:0)
sshクライアント側の仕様だから、セキュアは言いすぎかな。
改行→「~」をエスケープシーケンス扱いにしない設定のsshクライアントから繋げば通せる。
わざわざそうするのが面倒くさいから、ちょっとした横着避けか、啓蒙程度ぐらいにはなるけど。
Re:逆にセキュアになる・・・ (スコア:1)
回避策がいくらでもあることは気づいてた。ただ、苦情が多いということは誰も知らなかったんだなと。su - した痕跡もなかったし。
記号はキーボードによって場所が違うから嫌い (スコア:0)
USキーボード使ってるんだが、デフォルトのキーボードレイアウトが日本語の環境触るときに発狂する
Re:記号はキーボードによって場所が違うから嫌い (スコア:2, 興味深い)
業務上の理由で社内に日本語キーボードと英語キーボードが混在してる弊社、気を利かせて情シスがSSOのパスワードに使える記号を「!」「;」「.」「,」「<」「>」に制限してくれてる。
Re: (スコア:0)
キーコード変換はOSではなくキーボードがやればいいのに、と昔から思ってた。
Re:記号はキーボードによって場所が違うから嫌い (スコア:1)
先頭スペース (スコア:0)
先頭がスペース(0x20)のパスワードを使って面倒なことなった経験はある。
そのパスワードへの変更は受け付けられたのに、肝心のそれを使うシステムでは使えなかった。
仕方ないのでパスワードを再度変更しようとしたら、今度はパスワード変更に必要なパスワード認証すら通らなくなっていた。
「先頭にスペース」だったことを伝えてパスワードリセットを依頼したが、何もフォローなくリセットされただけで、パスワードに使えない文字の説明などは一切変更されなかった。
Re:先頭スペース (スコア:1)
使えない文字教えないことでセキュリティ上げてるつもりですよそれ。
Re:先頭スペース (スコア:1)
そうなのか。下手するとexploitである可能性すらあるんですけどね。