金銭が絡むサイトに対し8文字未満のパスワードを設定できなくするよう情報処理推進機構が呼びかけ 115
ストーリー by hylom
確かにそうなのだが 部門より
確かにそうなのだが 部門より
先日、日本航空の会員制サイトでは数字6桁のパスワードしか設定できないことが話題になったが、情報処理推進機構（IPA）の調査で、8文字未満のパスワードを設定可能なサービスが全体の6割に上ることが明らかになったという（NHKニュース）。
IPAはパスワードは8文字以上でなければ設定できないようにし、また記号なども使えるよう対策を呼びかけているという。
各行の動向 (スコア:2)
三菱東京UFJ：半角英数字・記号8～16桁。大文字と小文字を区別
三井住友：半角英数字4桁～8桁
ワンタイムパスワード：三井住友は無料配布、みずほは有料、三菱東京UFJは検討中。
パスワードを長くすると覚えきれない人が増えるのではないでしょうか。
結果としてパスワードの使い回しが増えるかもしれません。
Re:各行の動向 (スコア:1)
銀行ATMの暗証番号が数字4桁ってのはもう変えようがないんすかね。
#ネットバンクは未だにセキュリティ信用できずに使えないというヘタレ
docomoのパスワードも数字4桁で、何(2?)種類かあるのもわけわかんなくなるので結局全部一緒に設定してしまった。
#頭悪いととことんゆるゆるになるなぁ・・・
でかいとこで一社でいろんなサービスをしていて、サービス毎でパスワードを別個に設定させてるところはいらっとする。
全部いっしょにするのも漏れた時怖いし、微妙に変えるとあまり使わないサービスのパスワード中々思い出せないし。
#やっぱり頭悪いと(略
Re:各行の動向 (スコア:2)
ATMの暗証番号4桁は、「3回ほど間違えたら使用停止（復旧には窓口で本人確認）」という運用だから許されるのだと思っています。
＃とはいえ、語呂合わせで覚えるため、もう少し桁数を多くできると個人的には助かるのですが。
Re:各行の動向 (スコア:1)
＞ATMの暗証番号4桁は、「3回ほど間違えたら使用停止（復旧には窓口で本人確認）」という運用だから許されるのだと思っています。
なるほど、運用実績もあるしそれで十分ってことですね。
バレタラ終わりってのは何桁にしても一緒だし。
Re:各行の動向 (スコア:1)
ちょうど、こんな事件がありました：サーファーの暗証番号は「１１７３」金引き出す : 社会 : 読売新聞（YOMIURI ONLINE） [yomiuri.co.jp]。
これは、リバースブルートフォース攻撃のようなものと言えるのでしょうかね？
Re:各行の動向 (スコア:1)
サーファー仲間内では常識だったのかな。
いい意味で、サーファーの人たちって思ってた以上に突き抜けてさわやかな世界っぽい。
Re:各行の動向 (スコア:1)
親族の生年月日とか電話番号下四ケタとか、顧客管理情報に乗ってる数字なんかはさすがに突き合せて警告出してるんでしょうね。
Re:各行の動向 (スコア:1)
ジャパンネット銀行は半角英数記号6～8文字。
ワンタイムパスワードトークン無料配布。
追加で、半角英数6～32文字のログインIDを設定可能。
設定するとログイン時に、店番号、口座番号、パスワード、の他にログインIDが必要になる。
適当に追加IDを設定しておくだけでも、
パス漏れやブルートフォースの対策になるかもしれない。
Re: (スコア:0)
覚えきれない人のために下限は緩くしてもいいから、
設定したい人のために上限をあげて欲しい
Re:各行の動向 (スコア:1)
10文字までしか設定させないところが結構あるけど字数上限が小さいところは内部で生パスワードをもっているのでしょうね。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
ハッシュにかけているなら、どれだけ長いパスワードを設定してもハッシュのビット長より強くはならないわけで。
Re:各行の動向 (スコア:1)
いやや、ハッシュにかけていればこそ、最大文字数の制限がある必要はないんだよね。
元コメントはそれを指摘している。
#まあ、HTTP POST なので1GBとかあるとアレだけど。
Re:各行の動向 (スコア:1)
＞ユーザの平均パスワード長か、いっそ最長パスワード長よりハッシュのビット長が長ければいいんじゃないの
別にパスワードはコンフリクトしてもよいので、パスワード長の制限とは関係なく、ハッシュアルゴリズムと長さが「十分安全」ならそれでいい。
今なら、（ソルト付）SHA256なら十分といえるんじゃないでしょうか。
Re: (スコア:0)
記号が使えないのがイラッとする。パスワードを長くせずに強度を上げる効果的な手段なのに。
Re: (スコア:0)
不正処理のリスクを考えると記号は扱いづらい。
英字大文字小文字、数字まで許可しているならば少々文字数増やすより、
桁数を1桁でも増やすほうが明らかに（組み合わせ数が爆発的に増える）有効。
Re:各行の動向 (スコア:1)
インジェクションなんかを防ぐ為のエスケープ処理にバグを入れかねないのでやりたくないって話でしょ。
上にもある、技術力のなさって奴なんじゃないの。
桁数増やす方が効果的とかでなく、両方やればより効果的なんだから、やらない理由がない。
Re:各行の動向 (スコア:1)
PC以外だとUIの都合で文字種が制限されているのでは？
そういえば、iOSでフリック入力を使ってアクセント付きアルファベットをパスワードに設定するという話を思い起こしました：【裏技】「見破られにくいのに解除しやすい」魔法のようなパスコードをつくる方法 - たのしいiPhone！ AppBank [appbank.net]
Re: (スコア:0)
三菱東京UFJはスマホアプリという形であれば提供済みでは。
Re:各行の動向 (スコア:3)
で、リアルなハッキング成功事例ってパスワードの総当りなんかより電話窓口からのハッキングが多いいんでしょうね
#となると各種アカウントに使うメールアドレスは誰にも教えちゃいけないのかなと思う今日このごろ
この辺はキリがない (スコア:2)
いつしか8文字のパスワードが当たり前になると、
それらも収集されて総当りとかされるというイタチごっこなわけだから
最終的には生態認証くらいしかないんじゃないかとも思ってる。
# もちろん自動生成と一致コストは跳ね上がるので無駄ではないのはわかってる
Re:生態認証 (スコア:2)
いや、あそこのホカ弁で唐揚げ弁当買って、
こっちのコンビニでお茶買って、
途中の喫煙所でタバコ2本吸ってからでないと
認証通らないんだよ。
Re:生態認証 (スコア:1)
ATMの前でモンキーダンスのテンポを３分間狂わずやらんと認証通らないンすよ。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:生態認証 (スコア:1)
生体認証システムというものであれば必ずそこまで手間掛けてくれることを保証してくれるんだったらよいけど、
現状そこからはるかに隔たっているから個々人がグミその他の劣化コピーでアドホックに対処しないと割を食ってしまう。
というあたりが高いハードルだと思います。
Re:生態認証 (スコア:1)
あえてざっくり例えるなら、キーボード全体が生体で、AとDとGとJとLで認証していたものを、QとEとTとUとOで認証するように変更できればいいんですよね。
#・・・位置が上にズレてるだけだから盗生体でも認証されそうだ、というのはあくまで例なので棚に上げといて。
システムが一つしかないなら以前とは違うパターンにさえなってくれれば大丈夫ですが、複数システム利用しててそれぞれがバラバラに変更された場合、「たまたま以前盗まれたパターンと同一」になっちゃうかもしれないくらいがリスクかな（上で示したくらい組み合わせ数が多ければ杞憂ですが）。
人差し指が盗まれたなら中指を使えばいいじゃない、とかいうことにしちゃうと、どのサービスにどの指を充てたのか覚えてないといけないのが難点だしなぁ。
直接関係ない話ではありますが (スコア:2)
パスワードと言えば、いろいろやられた……。
・「8文字以上32文字以下」という設定だったので、32文字のパスワードを入れたら、「エラー」とだけ言われてはじかれた。（実際には、30文字しか受け付けなかった、30文字+CR+LF=32文字？）
・同じく、16文字以下ということだったので、パスワードジェネレータが生成した、16文字のパスワードを入れたら、「パスワードが単純すぎてアウト」とはじかれた。（たまたま、数字が含まれていなかったせい。しかし、エラーメッセージをもう少し工夫して欲しいかなと）
・「８文字以上」という指定（上限が書かれてない）だったので、16文字のパスワードを入れたら、「パスワードには、英字と数字を必ず含めてください」とはじかれた。英数字どちらも入っているのに。（実際には、12文字が上限だったので長すぎてはじかれた。これは、エラーメッセージが間違っているだろう）
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re:直接関係ない話ではありますが (スコア:1)
（2番目のサイトは、まあ、間違いとは言い切れないけど）
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
桁数制限の効果 (スコア:1)
パスワードの使い回しをされてたら桁数制限の効果は、ほぼ無いですよね。
Re:桁数制限の効果 (スコア:1)
そんな事言って、
「他サービスと同じパスワードが設定できなくするように」
と言う通達でも出したら失笑するんでしょ？
Re: (スコア:0)
それはさすがに失笑する。
どうやって実装するんだろう。
パスワード登録時に他サービスにアクセスして
「ご入力のパスワードで他サービスにログインできたので、登録できません」とか？ ダメだよなあ。
Re:桁数制限の効果 (スコア:2)
パスワードをユーザに作成させなければ良いと思ってます。乱数生成したものを発行し、それを使わせるだけ。パスワードの再発行も同様に。
ただし、これを暗記、手入力はさすがに難しいので、ブラウザのパスポートマネージャに記憶させるために、発行時に一度、ログインフォームに最初からvalue値を設定して、ユーザにログインさせれば、今の大抵のサービスより使い勝手も向上するかと思います。
モダンなWebブラウザはパスワードマネージャが搭載されていますし、端末間での共有もサポートされているものが多いので、複数のデバイスでのアクセスも問題無いと思います。
また、パスワードマネージャの利用を阻害しないように、パスワードだけを問い合わせるようなログインフォームを作らないように、注意が必要だと思います。
Re:桁数制限の効果 (スコア:1)
ワンタイムパスワードェ……
システムで強制生成される固定パスワードには、
その規則性を突破される可能性があって危険なんでしたっけ。
どっちにしろ生成されたタイミングを狙われたら危険なのはワンタイムパスワードも変わりはしませんが……
Re: (スコア:0)
サービス間で共用は駄目だけど、端末間での共有の共有はOKと言うのが理解できません。
○○銀行のサービスは危険で、Google/Mozillaのサービスなら安全と言うことでしょうか？
Re: (スコア:0)
端末間で共有しても、リスト攻撃にあいません。
Re: (スコア:0)
銀行間で共有しても漏れなきゃリスト攻撃にあいませんよ？
パスワードマネージャなどで共有する場合、大抵GoogleなりMozillaなり何らかのサーバを介しますが、
そこで漏れることは想定されてませんか？
Re:桁数制限の効果 (スコア:1)
おっしゃることは正論なのですが、八文字「以下」しか認めないとか、数字しか認めないなどと言っている銀行に比べて、
普通に常識的なパスワードが設定できて、ちゃんと暗号化されて保存されていることが自分で確認できるブラウザ、どっちが信用できるかと言われたら、僕は断然ブラウザの方を支持します。
Re: (スコア:0)
パスワードを共有すると、共有している中で一番弱いところから漏れるのになんで銀行しか出てこないんですか?
Re: (スコア:0)
個人的には、あまり短いと忘れにくく工夫したパスワードが作れないんだよね。
で、個人的にってどういうことかというと、サービス名を連想させる文字列を入れてるもんで。それで使い回しを避けてる。
Re: (スコア:0)
8文字か…なら！ (スコア:1)
password
abcd1234
hogehoge
Re:8文字か…なら！ (スコア:1)
slashdot
ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
8文字以上のパスワードしか受け付けないようにしたり、記号を必須にしたりすれば、現実問題としてパスワードの使い回しがより頻繁に行われるようになるだけ。IDがメールアドレスならば、リスト型アカウントハッキングが余計に増えます。
もっと現実的な対策として、私は、次のようなポリシーを提案します。
ランダム（暗号論的擬似乱数生成器もしくは現実的にはそれと類する推測不可能性を持つと思われるものに限る。某ネットバンクやJAL・ANAのような連番の数字は論外）な英数字のID（最低8文字）を管理側が一方的に割り当てる。
そして、ユーザーによる任意の文字列への変更は認めない。ただし、漏えいの可能性があるときにユーザーが変更できるように、新しいランダムの文字列への変更（再発行）はできるようにする。
そして、ユーザーには、IDを紛失しないように、手帳・パソコン内のテキストファイル・モニターのポストイットなど、複数の場所に書き留めておくことを推奨する。
IDは、"1", "I", "2", "Z" など紛らわしい文字は一切使わないようにすることが望ましいです。「"1" は使うけど "I" は使ってません、"I" に見えたら "1" を入力して下さい」とかいう管理者も居ますが、ナンセンスです。ユーザーにとってはそんなローカルルールをサイト毎に覚えてられませんから、紛らわしい文字は両方とも排除して、強度が下がるなら文字数を増やした方がましです。
4文字以上（数字4桁も認める）で、第三者に推測されないもの。ショルダーハック対策として、"1111"や"0101"～"1231"の月日パターンなどは利用不可とする。そして、ユーザーには絶対に書き留めず覚えることを要求する。
そして、入力元のIPアドレスなどに関係なく、連続して4回以上入力したら、ロックする。 ただし、きちんとしたパスワードを設定したいユーザーのためにアルファベット・数字・記号（ASCII印字可能文字は全て）を使えるようにする、文字数の上限を引き上げるといった対策はすべきです。
ポイントの利用や、金銭が絡む取引などでは、これに加えてワンタイムパスワードを入力させる。金額の低いものは、電子メールでの都度送付で構わない。銀行振込などの大きな金額が動くものに関しては、ハードウェアトークンによるトランザクション署名 [ftsafe.co.jp]を必須とする。トランザクション署名は、シンガポール・香港などの銀行では一般的にに使われていますが、日本では、三井住友銀行やゆうちょ銀行が対応トークンを配布したものの、まだサーバ側での対応例は無いようです。
-
JAL や ANA が数字のみ4桁～6桁のパスワード（というより暗証番号）で不正アクセスが多発したのは、IDの強度が不足していた（数字のみ・連番など推測可能）からです。
IDが推測不可能であれば、リバースブルートフォースアタックも成立しません。
ユーザーを信頼せず、IDを強制的に強度の高いランダムなものにしてしまい、パスワードはショルダーハック（IDをメモした手帳やポストイットを見ることができる人による不正アクセス）を防ぐためのものでサービス間での使い回しはやむを得ない（現実的に防げない）ものと考えれば良いのです。
パスワードが使いまわされ、他のサイトから漏えいしたとしても、IDが推測不可能であれば、今流行のリスト型アカウントハッキングも成立しません。
また、この4回連続でパスワードを間違えたらロックすることで、ショルダーハックを防ぐことができます。IDを書き留めた手帳やポストイット・PC内のテキストファイルを見れる立場の人が居たとしても、せいぜいアカウントをロックさせて一時的に利用不可能とする嫌がらせがせいぜいです。（そもそも、それができる立場なら、物理的にパソコンを壊す、手帳を破り捨てるといった方法もとれるので、現実的にそこまでは心配ないでしょう。身内や同僚の嫌がらせによってアカウントをロックさせられるのが心配な特殊な方は、IDを暗号化してパソコンに保存すれば良いでしょう。）
このように、ユーザーが設定するパスワードを信頼せずに、任意の文字列への変更不可能で推測不可能で強度を持つIDを強制的に割り当てれば、殆どのオンライン攻撃を防ぐことができると思われます。
ワンタイムパスワードは異なる運営会社のものを使って欲しい (スコア:2)
ベネッセやNTTデータの派遣社員のように、サーバ側のデータを根こそぎ持っていかれるとアウトです。
せめて異なる運営会社のOTPを使用して欲しいですね。
金融機関が相互乗り入れしてくれると、ユーザ側のキーホルダーのサイズも減って助かります。
Re:ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
アタックをしかけること自体は当然可能ですが、それにより不正アクセスを成立させることのできる確率は極めて低く現実的ではないので、「リバースブルートフォースアタックも成立しません」と書きました。
推測不可能なIDというのは、例えば、次のようなものです。これは、ランダムな文字種50文字（英数記号から視認した際に紛らわしい文字を排除）の10桁です。
ユーザーID: K9eJP@N4Ae
5010 = 97,656,250,000,000,000 通りあります。
Web経由で、毎秒何千回もログインを試みるのは現実的ではありませんので（普通のWebサーバは、同一IPアドレスからの大量のWebアクセスは、DoSと判断してブロックする設定にしてあります。BOTを使って多数のIPアドレスを使い分けたとしても限度があります）、仮に、ユーザーIDだけで認証していたとしても（パスワード無し）、破ることができる確率は天文学的に低くなります。
更に、最低4桁だとしてもパスワードもあれば、リバースブルートフォースアタックが成功する確率は更に低くなり、現実的には不可能と言えます。
「ブルートフォースアタック」については、そもそもユーザーIDを知っていることが前提となりますので（IDを固定してパスワードを変える攻撃のため）、書き留めておいたユーザーIDを見ることのできる立場の人しかできませんし、 #2659341 に書いたように、4回間違えたらロックする仕様ですから、仮に家族や同僚などのIDを知ることができる人が、ブルートフォースアタックをしたとしても、ほぼ失敗します。（もし、物理的にPCに接触できる立場ならば、キーロガーを仕掛けた方が効率的です）
Re:ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
英数字8文字(62種類)から、紛らわしい文字を排除して50種類としても、8文字なら、39,062,500,000,000 通りもあります。
ローカルでパスワードのハッシュ値（digest value）から元のパスワードを割り出すような攻撃であれば、現実的な時間でできてしまいますが、インターネット経由であれば困難です。
毎秒100回のアクセスを続けたとしても、全通り試すには、約12387年間かかることになります。
同一のIPアドレスから連続してログインを試みるような攻撃を続けていてはブロックされますから、IPアドレス（BOTなどの踏み台）も多数必要となります。
くだらない (スコア:0)
そんな下らないことよりもまず先に、Internet Explorer でしか閲覧できないとか、しまいにはInternet Explorer 6～10以下でしか閲覧できない金銭が絡むサイトをどうにかしてくれ。
今時Active X必須の金銭が絡むサイトについてもどうにかしてくれ。
いくら8文字以上のパスワードを強制したところで、それらが満たされない限り無意味。
更にいうとパスワードの最大長が30以下の金銭が絡むサイトもどうにかしてくれ。
バカが自らの責任でもって8文字以下のパスワードを使用し、勝手に自爆するのは構わない。
だが何故そうでない我々が、高々12文字以下の「弱い」パスワードの使用を強制されねばならんのだ？
最低文字数よりも最大文字数の少なさの方を先にどうにかしろ。
# 某フォントのライセンスといい情報処理推進機構は、いつもどこかズレてる。
Re: (スコア:0)
IE専用の金銭が絡むサイトなんてここ数年お目にかかっていませんが、実例はありますか？
Re: (スコア:0)
独自暗号化が事実上の標準になってしまったのでいまだにActiveX漬けから抜けられない南朝鮮人なんじゃないの?
Re:くだらない (スコア:1)
ANAとJAL (スコア:0)
> 先日、日本航空の会員制サイトでは数字6桁のパスワードしか設定できないことが話題になったが、
それはだいぶ前の話題で、最近の話題は２段階認証で生年月日の入力を求める、
というタコ仕様が追加されたというものじゃなかったかな。
一方で、4桁の数字だけだったANAは、9月くらいから8桁以上の英数字に
変更されるそうだ。
情報ソースは貼るのが面倒くさいので貼らないから、利用者は自分で調べな。
Re:ペースト禁止もやめるよう呼びかけていただきたい (スコア:2)
これに一票。
インスペクタで強制的にValue値書き換えてますが、大変面倒。