ﾊﾟｽﾜｰﾄﾞの設定で･･･ﾊﾟｽﾜｰﾄﾞは長い方が堅固だって事はわかりました｡ 6文字以上40文字以内程度が多い中で､たまに10文字以内もっと少ない8文字以内なんてと…

ｾｷｭﾘﾃｨの強さをどの程度に設定するかという､ｼｽﾃﾑ設計の差によるものと思います｡

長くすればｾｷｭﾘﾃｨの強度は強まりますが､ﾊﾟｽﾜｰﾄﾞを記憶･保存するﾕｰｻﾞｰの負担も重くなります｡また､ｼｽﾃﾑでﾊﾟｽﾜｰﾄﾞを保存するｻｰﾊﾞｰの記憶領域も多く必要になります｡

ﾊﾟｽﾜｰﾄﾞの文字数が少ないｻｲﾄは､ｾｷｭﾘﾃｨの強さを追求する必要があまりないｻｲﾄかもしれません｡

非常に長い文字数のﾊﾟｽﾜｰﾄﾞを力ずくで破るためには､ｺﾝﾋﾟｭｰﾀｰで何度も挑戦しなければなりませんが､悪意のあるﾊｯｶｰがそこまでして破って､得になるというｻｲﾄでなければ､非常に長くするのは上記のようなﾃﾞﾒﾘｯﾄの方が大きくなります｡

8文字が短いとのことでしたが､一般的な､数字､英小文字､英大文字の組み合わせで､1文字につき62通りあります(ｱﾙﾌｧﾍﾞｯﾄ26文字×2+数字10文字)｡これが8文字になると｢62の8乗｣(62を8回かけたもの)となりますから､組み合わせの数は非常に多くなります｡

これだけのものを時間をかけて破るかどうかを考えると､十分な桁数かどうか検討する材料になるのではありませんか｡

ｵﾝﾗｲﾝ･ｸﾗｯｷﾝｸﾞ(対象ｼｽﾃﾑに対して､ﾛｸﾞｲﾝ試行を繰り返す)に関しては､きゃづみぃさんが書かれている通り､短めのﾊﾟｽﾜｰﾄﾞでもｾｷｭﾘﾃｨﾚﾍﾞﾙを高くする事は可能です｡

ただ､

たとえば 1日に 3度間違えたら､ﾛｸﾞｲﾝできないとか｡

を､仮に｢同一ｱｶｳﾝﾄに対して3度間違えたら｣としたら､正規のﾕｰｻﾞもﾛｸﾞｲﾝできない状態が発生する事になります｡接続元の IP ｱﾄﾞﾚｽと組み合わせて､とすれば､その可能性は低くなりますが､例えば､ｱﾌﾟﾘｹｰｼｮﾝにｱｶｳﾝﾄ名とﾊﾟｽﾜｰﾄﾞを覚えさせるような物を使っていて､そっちの修正をせずにﾊﾟｽﾜｰﾄﾞを変更してしまうと､本人が意図しなくてもﾛｯｸｱｳﾄされる可能性もあります｡

こういった利便性の低下をどうやって避けるか､というのはｻｰﾋﾞｽ側にとっては課題になります｡例えば､あるﾕｰｻﾞが､普段は接続して来ない海外の IP ｱﾄﾞﾚｽから接続してきた場合には､通常のﾊﾟｽﾜｰﾄﾞ認証の他に､携帯ﾃﾞﾊﾞｲｽ等を使った2要素認証要求することで､普段の利便性を損なわずに､警戒すべき状況にはﾌﾟﾗｽｱﾙﾌｧの認証処理を要求する､といった事もあります｡ただ､こういった仕組みは､ｻｰﾋﾞｽの提供側に取っては大きな負担になる(｢警戒すべき状況｣を判断するためのﾁｭｰﾆﾝｸﾞが常に必要だったり､ｼｽﾃﾑの導入･運用費用がかかる)ので､かなり大規模なｻｰﾋﾞｽか､非常に高い信頼性･機密性が必要な場合に限られます｡

以上が､ｵﾝﾗｲﾝ･ｸﾗｯｷﾝｸﾞの場合で､もう一つ､ｵﾌﾗｲﾝ･ｸﾗｯｷﾝｸﾞというのがあります｡これは､ｻｰﾋﾞｽ側が保管しているﾊﾟｽﾜｰﾄﾞ情報が漏れてしまっている場合です｡多くのｻｰﾋﾞｽではﾕｰｻﾞのﾊﾟｽﾜｰﾄﾞをそのまま保管しているのではなく､何らかの暗号化に類する処理を行い､元のﾊﾟｽﾜｰﾄﾞが何かが分からないようにしています｡

この｢暗号化に類する処理｣をした後のﾊﾟｽﾜｰﾄﾞ情報から､元のﾊﾟｽﾜｰﾄﾞを見つけ出すのがｵﾌﾗｲﾝ･ｸﾗｯｷﾝｸﾞです｡この場合､単純にﾊﾟｽﾜｰﾄﾞから同じ計算処理を行って､手元にあるﾊﾟｽﾜｰﾄﾞ情報と合致するかを確認する､という事を繰り返すことになるで､ｵﾝﾗｲﾝ･ｸﾗｯｷﾝｸﾞの時のような｢何回失敗したらﾛｸﾞｲﾝできない｣という対策は意味がありません｡

このような最悪の事態でも､元のﾊﾟｽﾜｰﾄﾞを復元できないようにするには､ﾊﾟｽﾜｰﾄﾞの長さを長くする事が有効です｡

去年末に Windows のﾛｸﾞｵﾝ時のﾊﾟｽﾜｰﾄﾞで､8文字以下なら 5.5 時間で元のﾊﾟｽﾜｰﾄﾞを見つけられる､という話が出たのですが､これはまさにこの｢ｵﾌﾗｲﾝ･ｸﾗｯｷﾝｸﾞ｣での話でした｡手前味噌ですが､その事に関してちょっと書いたことがあります｡

こんなに早く､この日が来るとは... - JULYの日記

この｢8文字以下 5.5 時間｣のｼｽﾃﾑを使っても､10 文字のﾊﾟｽﾜｰﾄﾞなら年単位の時間がかかります｡

で､ようやく本題w｡

8文字なんて言ってるｻｲﾄは､よっぽどｾｷｭﾘﾃｨに自信があるのでしょうか？？

個人的な見解ですが､自信があるのではなく､｢知らない｣だけだと思います｡

使える文字に制限が有るのは､Web ｻｲﾄ側の作りが面倒になるので｢記号は一切使えません｣としてしまう､というのは分からなくもないですが(とはいえ､作り手の技術力の無さを自ら白状するような感じがしますが)､ﾊﾟｽﾜｰﾄﾞ長の上限を短くすることにﾒﾘｯﾄはありません｡

強いて言うと､古い UNIX の場合に､有効なﾊﾟｽﾜｰﾄﾞ長が8文字までだった､という事はありますが､今時､そんな制限があるｼｽﾃﾑは無いですので､そういった古いｼｽﾃﾑを引きずっている場合でない限り､全く意味がありません｡ましてや Web ｻｰﾋﾞｽの場合､ｻｰﾋﾞｽのｱｶｳﾝﾄと OS のｱｶｳﾝﾄを結びつける事は､普通､やらないので､ﾊﾟｽﾜｰﾄﾞ長は Web ｻｰﾋﾞｽを作る側が勝手に決める事ができます｡

昨今､｢ﾊﾟｽﾜｰﾄﾞを使いまわすな｣という事が重要になってきていますが､ﾊﾟｽﾜｰﾄﾞ長の最大文字数が小さいところは､ﾕｰｻﾞ側が｢このｻｲﾄから漏れたらﾔﾊﾞいことになるかもしれない｣という覚悟をもって使った方が良いです｡私もそういうｻｲﾄを一つ知っていますが､ここのﾊﾟｽﾜｰﾄﾞはまっさきに他と違うﾊﾟｽﾜｰﾄﾞにしました(今は､ﾊﾟｽﾜｰﾄﾞ管理ｿﾌﾄを使ってますが)｡

ささった碧い星がとても痛いので､登場することにしました｡
＃と言っても､おおよそのことは書かれちゃってますが｡

http://ascii.jp/elem/000/000/784/784387/
↑なんかで書かれているのは､

※解読時間は1秒間に33億ﾊﾟﾀｰﾝを試行できるGPUを利用したﾏｼﾝで解読を実施した場合の想定時間｡
http://ascii.jp/elem/000/000/784/784387/index-2.html

というとてつもない速度でのﾊﾟｽﾜｰﾄﾞのｱﾀｯｸを､普通に手に入れられるPCでできちゃうのがやばいぜ､って話です｡

でも､普通のｻｲﾄにﾛｸﾞｲﾝするときのことを考えてください｡
ﾊﾟｽﾜｰﾄﾞをﾎﾟﾁﾎﾟﾁ打って､｢ﾛｸﾞｲﾝ！｣ってやってから返ってくるのに､ちょっと待たされますよね｡
仮に､0.01 秒待たされるとしたら(こんなに早いわけない)､一秒間に 100ﾊﾟﾀｰﾝしか試せません｡
総当たりで行くとしたなら､先程の理屈の 3000万倍の時間がかかるはずなので､17年以上かかることになります｡

No.1 で､きゃづみぃさんが書いた､｢一日三回間違えたら｣は極端にしても､千回間違えたら､くらいで十分にｶﾞｰﾄﾞできます｡
＃という言い方は正しくないのですが､詳しくは後述

No.3 で JULY さんが書かれているように､やばいのはﾊﾟｽﾜｰﾄﾞを記したﾃﾞｰﾀが盗まれた場合です｡
でも､文字数だけの問題じゃないんです｡

ﾊﾟｽﾜｰﾄﾞは､普通のｼｽﾃﾑでは､そのまま保存されていません｡
例えば､｢Fj3SiT6!｣というﾊﾟｽﾜｰﾄﾞは､そのまま保存されているわけでは無くて､こんな感じの文字列に変換して､保存されてます｡

475e9d90f2b18f8ed9a5c99c955c69bb9b63d72abc3aed77b40921f0979822ad

元の文字列から､この長い文字列を計算で出すのは､ﾊﾟｯとできるけど､長い文字列から元の文字列を計算では出せないような処理になってます(ﾊｯｼｭ値計算って言います)｡こういう処理がされてるから､｢全ての文字の組合せをﾁｬﾚﾝｼﾞする｣みたいな攻撃になるんですけれど｡

んで､さっきの長い文字列に､もう一回､同じ処理をすると､こんな結果が得られます｡

ee4a4e61afedd1c094729b2601434a53de9a91cc544580b40b2363bedb65b43a

全然､別の文字列になりました｡
この同じ処理を繰り返す､の回数を隠しておけば､ｱﾀｯｸする人は､その全てを確認しなければいけなくなります｡
｢1000回くらいやってるかもしれない｣と想像させたら､｢1秒間に33億ﾊﾟﾀｰﾝ｣を｢1秒間に330万ﾊﾟﾀｰﾝ｣まで減らせます｡
解読時間も1000倍になります｡
こういうのを｢ｽﾄﾚｯﾁﾝｸﾞ｣って言います｡

他にも対策があって､｢ｿﾙﾄ｣っていうのがあります｡
ﾊﾟｽﾜｰﾄﾞの｢Fj3SiT6!｣に､別の文字をくっつけてさっきの計算をやります(お塩をﾁｮｲ足しです)｡
例えば､hatena という文字列をくっつけると､

f77a21e3441127d07b68747aa766fc1306fc134e51ce4c60fb555e7f824a5029

また､全然別の文字列になります｡
くっつけてる文字列が分からなければ､8文字のﾊﾟｽﾜｰﾄﾞが実質8文字以上のﾊﾟｽﾜｰﾄﾞになっているので､総当たりでｱﾀｯｸをかけてくる人は､ﾊﾟｽﾜｰﾄﾞを当てるまで､かなりの時間がかかることになります｡

逆に､ﾊﾟｽﾜｰﾄﾞを解析しようとする人も､工夫をします｡
総当たりで最初からﾁｬﾚﾝｼﾞするのではなく､ありがちなﾊﾟｽﾜｰﾄﾞを最初に試してみます｡
例えば､こんなの｡
http://itpro.nikkeibp.co.jp/article/NEWS/20110216/357251/
http://www.j-cast.com/kaisha/2011/12/01114760.html?p=all
http://screwdesk.com/wp-content/uploads/2013/04/top-10000-passwords.txt
http://andres.com/wp-content/uploads/data.txt

ebookjapan というところであった､ﾊﾟｽﾜｰﾄﾞｱﾀｯｸについての報告｡
http://www.ebookjapan.jp/ebj/information/20130405_access.asp

･前回のご報告までは｢複数のIPｱﾄﾞﾚｽからﾛｸﾞｲﾝﾍﾟｰｼﾞに対して機械的に総当たり攻撃等を行う大量ｱｸｾｽ行為(ﾌﾞﾙｰﾄﾌｫｰｽｱﾀｯｸ)｣とご説明しておりましたが､詳細調査の結果､｢不正の疑われる複数のIPｱﾄﾞﾚｽからﾛｸﾞｲﾝﾍﾟｰｼﾞに対して､予め持っていたﾛｸﾞｲﾝIDとﾊﾟｽﾜｰﾄﾞの適用可否を試行する大量ｱｸｾｽ行為｣であることが判明いたしました｡

?つまり､大量ｱｸｾｽ行為を仕掛けてきた者は､当社以外の他のｻｰﾋﾞｽなどで他のｻｰﾋﾞｽのﾛｸﾞｲﾝIDとﾊﾟｽﾜｰﾄﾞを不正に入手し､ﾕｰｻﾞｰがﾛｸﾞｲﾝIDとﾊﾟｽﾜｰﾄﾞを共通に設定している可能性を狙って当社ｻｰﾋﾞｽに不正にﾛｸﾞｲﾝしようとし､上記件数についてはﾛｸﾞｲﾝに成功してしまったということです｡
?そのように判断した根拠は､一つのﾛｸﾞｲﾝID(ﾒｰﾙｱﾄﾞﾚｽ)について試行するﾊﾟｽﾜｰﾄﾞの数の少なさです｡

○ ﾛｸﾞｲﾝ成立分
IDあたりPW試行回数該当ID数
1 386
2 347
3 37
4 4
5 5
注) 1つのﾛｸﾞｲﾝIDについてPWを試行した回数は最大5回までであり､1回しか試行していないのに正当したｱｶｳﾝﾄが半数近くを占めている｡

IDあたりPW試行回数	該当ID数
1	386
2	347
3	37
4	4
5	5

【結び】
ﾊﾟｽﾜｰﾄﾞの長さだけじゃなくて､他にも気にしなきゃいけないことがたくさんある｡
ｻｰﾋﾞｽ提供者も､利用者も｡