スラドに聞け：多くのシステムでパスワードに半角英数字と一部の記号しか使えない理由は何？ 101
ストーリー by hylom
日本語を使えるようにすればセキュリティが向上するかも？ 部門より
日本語を使えるようにすればセキュリティが向上するかも？ 部門より
あるAnonymous Coward曰く、
アルファベット小文字だけのパスワードは簡単に推測される可能性があるため危険、というのは昨今では十分広がっていると思うが、いっぽうでサービス・システムごとに利用できる文字種の制限が異なることが多い。ほとんどのシステムではアルファベット大文字・小文字と数字は利用できると思われるが、それ以外の#や@、-、_、\、+、*などの記号については使える場合と使えない場合がまちまちだ。しかし、こういった制限はなぜ行われているのだろうか？
teratailでの質問についてはいくつかの回答が寄せられているが、回答の1つに全角を許すと入力者が意図せず半角を入力してしまった際にエラーとなり、問い合わせなどが発生してサポートコストが増える可能性がある、というものがあった。これはそれなりに納得できる理由ではあるのだが、半角の一部記号が使えない説明にはなっていない。
もちろん、古いUNIXとの互換性という理由はあるだろうか、今でもそれを引きずる合理的な理由はあるのだろうか？
WAF の誤検出対策で使える記号を制限 (スコア:4, 興味深い)
例えば、AWS WAF で Body 全体 に対して "SQL injection match conditions" を適用していると、
のようなパスワードが送られてきた際に、SQLインジェクション攻撃だと判定して、HTTPリクエストごとブロックしてしまいます。
こういったケースでは、WAFの例外ルールを作る必要がありますが、Webアプリケーションの製作者とWAFの管理者が違うと面倒だし、URL変更やパスワード認証を行う箇所を増やした場合にも例外ルールを作り直さないとまた誤検出が発生してしまいます。こういった手間を避ける目的で、記号を使えなくしているシステムもあるのではないでしょうか。
# WAF のせいでかえって脆弱なシステムになるパターン
@_-# (スコア:2)
Re: (スコア:0)
(ﾟｰﾟ)(｡_｡)(ﾟ-ﾟ)(｡_｡)ｳﾝｳﾝ
Re: (スコア:0)
「ﾟ」（半角の半濁点）とか「ｰ」（半角の長音）とか、半角オンリーシステムで受け付けられない半角文字がやっかいだから…。
（それを言いだした半角カナが全滅するが）
「容易に推測可」という基準だとそもそもアルファベットを使う時点でダメなのでは？（思考停止
引きずる理由 (スコア:2)
むしろ、断ち切る理由というかタイミングを見失ったままズルズルと。
NIS上に旧いサーバー残っていたらそこにあわせざるを得ないし。
全角は (スコア:2)
UTF8じゃない端末とか。loginプロンプトで入力出来ないとか。
＃まあ大文字が出来な入力端末はさすがにないだろうけど。
あと特殊文字はキーボードがUSとJISで死ぬことがある。
この辺のサポートは嫌だな。
Re:全角は (スコア:1)
>＃まあ大文字が出来な入力端末はさすがにないだろうけど。
Caps Lockが入ってるのに気がつかないでパスワード通らない！ってな時もあったっけ。
#Num Lockとかも。
Re: (スコア:0)
まったくだ。
記号は日本語キーボードと英語キーボードでも位置が違ってたりするし、面倒ごとが増えるだけ。
＃ドライバが誤認識して、日本語キーボードなのに英語キーの配列で入力されたり。
ログイン前の厄介事はコマンドも打てないから「原因不明」になりやすくて、避けるに越したことはない。
そもそも記号をいれるメリットがないんだから、入れなきゃいいだけの話なのよ。
深く考えてないと言えばその通りが、深く考える必用もない。
考えれば考えるほど時間を浪費するだけなんだから、技術者の時間はもっと有意義なことに使うべき。
＃同様の問題に「元号のサポート」がある。「なんで未だに多くのシステムが西暦ベースで動いてるの？」
Re:全角は (スコア:2)
フランス語キーボード [wikipedia.org]やドイツ語キーボード [wikipedia.org]なんかだとQWERTYとはアルファベット配置が微妙に異なってるので(フランス語は数字も違うレベル)、英数字だけでも油断なりませんよ。
突き詰めると「パスワード入力はエコーバックしない」のが元凶ってことで、CUIログイン環境でも、今時のGUI環境でよくあるように「一定時間入力文字を表示してから*に変わる」とか「なんらかの操作でパスワードを表示確認できる」ようにする、といった話に進める必要があるのかも。
Re:全角は (スコア:2)
> CUIログイン環境でも、今時のGUI環境でよくあるように「一定時間入力文字を表示してから*に変わる」とか「なんらかの操作でパスワードを表示確認できる」ようにする
割合簡単に書けそうな気がしますが、使ってもらえますかねぇ。
＃多分半日くらい。
tty開いてtermiosかなんかでrawにして、selectでtimeooutみながら表示してLFして一行書く。だな。
Re: (スコア:0)
ローカルエコー返しちゃうのは script とかのログに残っちゃうから駄目じゃない？
Notes とかだと入力された文字がエコーされることはないけど、ログイン画面上の記号やら絵やらが、文字の種類に応じて動くから、自分が入れたのが途中で間違えれば気付く。
ってのはある。これもデータが集れば推測がたつから駄目なんだろうけど。
Re: (スコア:0)
Alt押しながらテンキーで「47」、もっかいAlt押しながらテンキーで「46」
とはいえキーボードドライバが対応してないとだめだろうけど
# Windows7で確認
Re:全角は (スコア:1)
> ＃ドライバが誤認識して、日本語キーボードなのに英語キーの配列で入力されたり。
キーボードの種類がそんなに増えると想定していなかったから識別方法を統一できなかったってことでしょう。
キーボードの識別情報に「言語識別(32bitくらい)」と「配列識別（32bitくらい；言語識別ごとにユニーク）」「メーカー識別(64bitくらい)」があり、何を優先に判断するかのルールが明確になっていれば、誤認識なんてなかったかあもしれませんが。
・・・と言いつつ、どうやって判別しているかは全然知らない門外漢なので、的外れでしたらごめんなさい。
> ＃同様の問題に「元号のサポート」がある。「なんで未だに多くのシステムが西暦ベースで動いてるの？」
・オペレータの入力ミス回避
・オペレータが和暦／西暦の変換をするのが面倒
・元号識別の入力欄を増やすと手間
・システム内が全部西暦なら、UIも西暦でいいじゃん
・UIが西暦で統一されていれば、申請書などの紙媒体の記入も西暦に統一しやすい
・元号サポートなんて考えなくても良い
・元号サポートなんて、国内だけのローカルルールなので、海外で困らないように
・国際化するうえで、元号サポートはユーザビリティの低下につながる
あたりが理由になるかと思います。
まぁ、昭和→平成時に苦労した人からすれば、一般的にはこういう回答が多いんじゃないかな？
よく考えればもっといろいろ出てきそうだけど、時間の無駄と指摘されそうなので、軽く考えた程度です。
Re: (スコア:0)
> 「なんで未だに多くのシステムが西暦ベースで動いてるの？」
何ベースだったら満足なん?
Re:全角は (スコア:1)
カッコ書きしてるし、皮肉を言っているんだと思う
Re: (スコア:0)
Date/time系の関数を使わず文字列やら年月日をそれぞれ数値で持って計算してるんなら
西暦ベースと言えると思うが、
今時システムの日付はDBやらシリアライズされたDate型の何かで
その実装が実は西暦なのかUnixTimeなのかなんて気にすることないよね。
そういう意味で西暦ベースのシステムなんてそんなにない気がする
表示と入力に西暦を使うってのは多いだろうが
Re: (スコア:0)
全角に変換するということはIME等の変換FEPを通して使うということなので、もしFEPがアレならセキュリティ的にアレなんじゃないんだろうかと思ってしまう。気休めなのかも知れないけど、何となくダイレクトな方が良い気がする。
>あと特殊文字はキーボードがUSとJISで死ぬことがある。
確かにキーボードのアルファベットより右側の記号は使い難い。だからなるべく上部の数字キーの位置にある記号を使いますね。
Re:全角は (スコア:2)
> だからなるべく上部の数字キーの位置にある記号を使いますね。
@とかで死ぬ。()の位置がずれて死ぬ。
ま、,./?!位が候補だな。(JISは全然使って無いので何がUSと同じ場所なのかすぐに出てこない)
＃viで:で毎回死んでる。
Re:全角は (スコア:1)
何の気休めにもならないけど、JIS配列では Shift 押せば ASCII コードで 0x10 あるいは 0x20 だけ離れた記号／文字があるんだけどな。
キー配列が誤認識されてても困らないように？ (スコア:2)
ではないかと思っています。
USとJISだけとってみても、英数は大体同じ配列ですが、記号はまったく
配列が異なるので、誤認識されていることにユーザが気づかず、結果正しくない
パスワードを入れ続けてロックアウト……
という事態を避けるのが目的ではないかと。
。
ポリシーを統一せよ (スコア:2)
「パスワードにはアルファベットの大文字小文字だけが使えて数字は使えない」
「パスワードにはアルファベットの大文字小文字を必ず混ぜて作らなければならない」
「パスワードにはアルファベットだけではなく必ず数字を混ぜなくてはならない」
って三種類のポリシーがあるのがめんどくさいので代表者を出して相撲で勝負を決めてもらって以後全部のサイトがそのポリシーに統一するのがいいと思います。クッソどうでもいいサイトのパスワードは安全性が低くて憶えやすいパスワードにしたいのにそれができないのは不便だ。
スラッシュドットが何をいうのか (スコア:1)
えいちてぃてぃぴーころんスラッシュスラッシュドット。。。
＃このネタが日本スラドでは通用しなく時代がくるのか
昔だとNIFTERMやAIRCraftが誤動作するから引用符が”＞”か">"論争などもあったっけ。
最初に決めた人に従ってる……のかも (スコア:1)
最初に決めた人が、自分が知ってる記号群だけを指示したので、
いまだにそれに従ってる……みたいなのはあったりするかも。要するに「何も考えとらん」ってやつ。
今は (スコア:1)
昔話は盛り上がってもらっていいとして、
＞アルファベット小文字だけのパスワードは簡単に推測される可能性があるため危険、というのは昨今では十分広がっていると思うが
今の常識は文字種増やすより文字数増やした方が安全、では。
Re:今は (スコア:1)
まぁ確かに「記号まで含めて8文字以内」とかより「アルファベット大文字小文字と数字で256文字以内」とかの方が覚えやすくて安全なパスワードを選べますよね。
＃マイクロソフトアカウントも最大文字数を64文字くらいまでに増やしてくれんかのぉ…。
Re:今は (スコア:2)
パスワードを例えば一文字ずつ送るようにすれば、文字数の上限を無くすのは容易だろうなって。
Re:今は (スコア:2)
#や@、-、_、\、+、*などの記号と同程度に揉めそうではある。
Re:今は (スコア:1)
推測可能性（ブルートフォース的な）云々はあんまり関係なくて
我々は「ハッシュはふつうにダダもれする」そして500円もらえる、という世界に生きている
だから昔話じゃないけど、サイトごとにパスワード変える、パスワードはエージェントに覚えておいてもらう
というオーソドックスな手法しかないんじゃないだろうか
そりゃ全角はやめた方が良いだろ (スコア:1)
半角カタカナならまだ理解できんでもないが、漢字やいろんな文字ともなれば直接入力できないのは厄介だろう。
誤入力に気づかないし、IMEが覚える事も、逆に違う方を学習してしまう事もあるだろう。
しかも見た目が同じで違う文字とかが山のようにあると考えると英数字記号が無難。
だいたいパスワードをキーボードの操作として考えれば英数字+シフトで十二分表現できてるし。
Re:そりゃ全角はやめた方が良いだろ (スコア:3)
昔、歌の一節をパスワードにしてました
# 昔過ぎて(1992-3年ぐらいか)制約が無かったので日本語でも通った
すると「どこを漢字でどこをひらがなで」書いたかわかんなくなっちゃって、
たまのログインに一苦労する事態でした
そのうちシステムのバージョンアップに伴い日本語が通らなくなりログイン不能に…
Re:そりゃ全角はやめた方が良いだろ (スコア:1)
すると「どこを漢字でどこをひらがなで」書いたかわかんなくなっちゃって、
たまのログインに一苦労する事態でした
パスワードは兎も角、自由に入力させる形式の「秘密の質問」では割とあるあるな印象。
それを見越して「ひらがなで入力してください」って書いてるシステムとかもあるけど。
Re:そりゃ全角はやめた方が良いだろ (スコア:1)
記号とはちょっと違うのですが、
POP3 サーバの実装よっては半角スペースの取り扱いが違っていて、そのために半角スペース入りのパスワードだと、POP3クライアント/POP3サーバの組み合わせで使えたり使えなかったりで困ったことがあります。
通常の素の POP3 プロトコルでは、
という手順を辿りますが、パスワードに半角スペースが混ざった場合、
と送っていけるPOP3サーバもあれば、
とダブルクオートで括らないとダメなPOP3サーバもあったりする、という…
パスワードにダブルクオートが入ってた場合の取り扱いになるとさらに混沌としていたかなぁ…
UNIXのログインパスワードは結構なんでもありなんで記号ごちゃ混ぜにして使ってましたが
そんなのに出くわして以来、無用なトラブルを避けるために、パスワードに使う文字で変なのことはしないようにすることにしてます。
Re:そりゃ全角はやめた方が良いだろ (スコア:1)
最低でも、RFC2640 の section 2-2 で言うところの FEAT コマンドが使えるようになっていないとダメなんだろうなあ。ほかにもいろいろあるんだろうけど以下略。
古いUNIXとの互換性 (スコア:1)
別に、UNIXでパスワードの文字制限なんて、特にありませんでしたよ。teratailで話になっているのは、昔のSystem V系UNIXで、#がerase、@がkillにデフォルトで割り当てられていた、という話でしょう。そんなのgettyの設定で何とかしろよ、という話ですが。そして、わざわざ、そんなものに互換性を取る必要なんてないように見えますが。
もちろん、そうでないシステムでもDelやCtrl+HやCtrl+DやCtrl+CやCtrl+MやCtrl+Jのような、使えない“文字”はあったわけですが、そのほかは記号も数字も空白も、たいてい使えましたよ。
今日日のパスワード (スコア:0)
EDwS5bq3x3jU
とか
r4POvfu6abce
とかだろ
記号や漢字を許したら、紙に書き留めて金庫に入れる時に写し間違えるじゃん
Re:今日日のパスワード (スコア:2)
0,1,2,O,Z,lとかも禁止しないと。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
ふっかつのじゅもん的なものでそういうのを禁止したことはある
ファイル名に使えないからよ (スコア:0)
*とかファイル名に使えないじゃん。
＃生パスワードをそのままファイル名にするなんて馬鹿なシステムはないだろって？あるんだよ・・・
Re:ファイル名に使えないからよ (スコア:2)
文字の制限を行う関数を使い回せて楽だから。
ASCIIの英数字だけだと、作るのが楽だから。
Re: (スコア:0)
これに近いけど、コードインジェクションを防ぐのに一番手っ取り早いと思われてる、といった理由じゃないのかなぁ？
Re: (スコア:0)
Linux だと、よっぽど変なファイルシステム使ってない限り、何の問題もなく作れる。
SFL の上なら Windows でも作れる。エクスプローラとかからのアクセスでは #002A みたいな別名が割り当てられるけどな。
Re:ファイル名に使えないからよ (スコア:1)
といいつつ実は0x20に弱いのであった
Re:ファイル名に使えないからよ (スコア:1)
いやまったくその通りであるが、
Unix系の文化はファイル名に空白文字を使わないというのは暗黙の前提なんじゃないかなと
わざわざ xargs -0 を用意しなければいけないように
なお Windows が "Program Files" としたのは、わざと空白を入れて「お前らちゃんとファイル・ディレクトリ名に空白が入ることを考えとけよな」というMSの意思と思った記憶がある。クォートめんどかった
寝た子を起すな (スコア:0)
ってのが大きいかと
ちょっとでも間口を広げると面倒な奴らが割り込んできて騒ぎ
Rustの識別子みたいな事になる。
文字種増やしても意味がない (スコア:0)
使える文字種を仮に倍にしたとしても、複雑さは1文字あたり1bitしか増えない。
そんな小さなことするより、パスワード長を1文字か2文字増やしたほうが効果高いよ。
Re: (スコア:0)
漢字が使えるようになったところで、誕生日の日付とか使われそうですね・・・一二一八とか。
Re:文字種増やしても意味がない (スコア:1)
ノ
うちの職場の事ですね。
おかげで、登録データのコードが全角やら半角やらが混じっていて、流し込みするときに手間がかかります。
そういうデータのフォーマット提供するときは、標準の文字種を固定ピッチフォントにして、全角が混ざればズレて一目でわかるようにしてあげます。
でも、コピペでフォント情報ごと張られると意味が無いんですよね。
インプット メソッド エディタ (スコア:0)
IMEが介在する可能性が上がるとパスワードが抜かれやすくなるからじゃないかと思ってみる。
これが現実 (スコア:0)
ベンダー「えっ、御社のシステムのパスワード文字数を英単語と記号を使えるようにして10桁に増やすんですか? 開発費500万円です!」
Re:これが現実 (スコア:1)
だからって10万円で受けられたら、それはそれでイロイロ抜かれそうでヤダ。