ANA、会員向けオンラインサービスのログイン用に8～16桁の「Webパスワード」を導入すると発表 31
ストーリー by hylom
JALはどうする 部門より
JALはどうする 部門より
headless 曰く、
全日空（ANA）は18日、公式ホームページでのマイレージクラブ会員向けオンラインサービス利用時のログインパスワードとして、現行のAMCパスワード（数字4桁）とは異なる「Webパスワード」を新たに導入することを発表した(ANA SKY WEB — 特別なお知らせ、ANA SKY WEB — Webパスワードのご案内、INTERNET Watchの記事）。
ANAマイレージクラブでは不正ログインによりマイルが不正に特典交換される被害が3月に発生しており、数字4桁のパスワードの危険性も指摘されていた（過去記事）。Webパスワードは9月4日午前5時から導入予定で、8～16桁の英字（大文字・小文字）と数字の組み合わせが利用可能。12月3日までは移行期間として現行のAMCパスワードを使用したログインも可能だが、12月4日からはWebパスワードのみ使用できるようになる。また、電子メールを使用したマイレージ特典交換時の本人認証などの導入も予定しているという。
なお、現行のAMCパスワードは、ANA予約センターやANAマイレージクラブ・サービスセンターへの問い合わせ時や、空港での自動チェックイン機利用時に引き続き必要になるとのことだ。
セキュリティーの (スコア:2, おもしろおかしい)
8〜16を考えた奴、本当出て来いよ (スコア:2, おもしろおかしい)
個人的なお話なのですが、僕はいくつかのパスワードを複数のシステムの中で適宜使い回しております。で、記号を含まないパスワードはなぜか見事に 7 文字と 17 文字ばかりで、一方、記号を含むと 14 文字とか 15 文字とかのパスワードもあります。
そしてなぜか今のところ、パスワードに記号を含めないことを条件にしているところばかり 8〜16 文字の制限があってヴァアアアですよヴァアアアア。
Hiroki (REO) Kashiwazaki
Re: (スコア:0)
せめて、パスワード設定しようとする日に更新したファイルハッシュから適当な長さを取り出す位はしましょうよ。。
まあ、何十個もあると覚えられないし、スマホだと入力困難な記号混ざるので微妙ですが。
Re: (スコア:0)
記号を含む14文字とか15文字から記号を抜けばお望みに近い文字数になるような気がしますが。
もしかして半数以上の文字が記号のパスワードならごめんなさい。
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
でも文字数の上限はできるだけ多くすべきだよね
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
ユーザ数1000万だと
255Bytes×10M = 2,550M = 2.5GBytes
2.5GBytesにしかならないじゃない。ユーザ数が10万だったら25MBytesにしかならないよ!?
まあ、パスワード文字列自体ではなくパスワードのハッシュを保存するはずだし、DBに保存する時には余計にディスク容量を使用するかもだけれどもこのくらいのオーダーだよね。
パスワード文字列に長い文字数を許可すると「パスワードがわからなくなるユーザの割合が増えて、ユーザサポートが大変になる、だからヘッポコパスワードにして楽にサポートできるようにしよう」なのかなぁ?
仕様決定の際に、何もわからない上役が「その方が安くできるんだろ?」みたいな感じで仕様を押し付けたんだろうか。
JALとANAの場合には特殊な企業文化が主な理由で、ヘッポコパスワード仕様が決められたんじゃないかと思ってしまっています(私の偏見ですが)。
Re: (スコア:0)
生パスワード入れる前提の容量計算も、大概なへっぽこだと思う
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
素晴らしい、ヨロシクお願いします！
Re: (スコア:0)
最もお手軽なハッシュsha1なら40Byteなので、
40*10M = 400MB
だね。
部門名 (スコア:0)
なぜ最大16文字？ (スコア:0)
ハッシュ化してDBに保存するなら、16文字なんて中途半端な制限を設けず255文字でも1024文字でも保存容量は変わらないはず。
まさか・・・・まさかねえ。
ハッシュ化にはデメリットもある (スコア:3, 興味深い)
リスト型攻撃が流行していることもあり、パスワードのハッシュ化を推奨する意見が多くなりましたが、パスワードのハッシュ化にはメリットだけでなくデメリットもあるのです。
「パスワードをハッシュ化しなくて良かった！」というモデルケースを挙げてみます。
【モデルケース1】
ダイレクトメール発送の業務委託先から、全顧客のお客様番号と生年月日を含むリストが漏えいしてしまった。（パスワードはダイレクトメール管理に不要なので漏えいしていない）
その後、アカウントに不正アクセスされてマイル交換されたというクレームが多発したので、調べてみたところ、クラックされたアカウントのパスワードは "S43.5.1"や"S531203" といった生年月日を含んだものだった。
緊急対策として、パスワード中に、生年月日に含まれる数字が4文字以上含まれていて、かつそれ以外の英数字が4文字以下のアカウントでのマイル交換を一時できない状態とした。それ以降、不正なマイル交換は殆ど無くなったようだった。
もし、パスワードをハッシュ化していたら、全顧客のマイル交換を停止して、全顧客に対してパスワード変更を要求せざるを得なくなっていただろう。
そうしたら、サポートセンターの電話がパンクし、予約や予約変更の電話もつながらなくなって、会社の損害額がとんでもない金額になっていたかもしれない。（仮に、予約受付の電話番号と、マイル交換に関する問い合わせ電話番号を分けていたとしても、顧客はその番号に繋がらなかったら他の番号に掛けることが多い。特に今回のモデルケースのように、情報の漏えいといった過失があると、怒った顧客は違う窓口の番号にもかけてくる）。
※これは架空のモデルケースです。実際の事例ではありません。
【モデルケース2】
ある顧客から、「80万円相当のマイルが無くなってしまった」というクレームが。
さっそく、ログイン履歴を調べてみると、当該のアカウントに対して、中国のIPアドレスから、"passw0rd0", "passw0rd1", "passw0rd2" というパスワードでログインを試みる記録があった。
当該顧客のパスワードは "passw0rd2" だったので、3回目のアクセスで不正ログインされてしまったようだ。（"password"+数字 や "passwd"+数字 というパスワードは使用できなくしていたが、"passw0rd" はブラックリストから漏れていたようだ）
約款には、顧客に対してパスワードは第三者に推測されにくい文字列にすることを要求しており、それに反する場合には責任を負わない旨を明記していた。顧客にはパスワード管理に関する重大な過失が認められるので、不正利用されたマイルは補てんしないことにした。
もし、パスワードをハッシュ化していたら、顧客の設定したパスワードに問題があることを特定できずに、80万円分の損失が出ただろう。
※これは架空のモデルケースです。実際の航空会社の約款や、その解釈、対応とは一切関係がありません。
--
なお、単純なWebのみのシステムで、大きな金銭が関わらないものであれば、パスワードはハッシュ化した方が良いと思います。特に、スラッシュドットのアカウントシステムのような、セキュリティ管理がいい加減なシステムの場合には、漏えいして他のサイトにリスト型攻撃などの迷惑がかからないように、絶対にハッシュ化すべきです。（といってもログイン画面にSSLすら使っていないようなので、サーバでハッシュ化したところで通信経路で漏えいしてしまう危険があるが……）
逆に、銀行や証券会社、航空会社のように、システムが大規模でWebだけでなく窓口や電話・その他様々なチャネルと連携していて、多額の金銭が絡む場合には、ハッシュ化しない方が良いと思います。
以前、銀行のスキミングした磁気キャッシュカードのデータと誕生月日で、ATMから不正に預貯金を引き出す犯罪が流行したことがあります。
その時、銀行は誕生月日を暗証番号にしている顧客に対して、電話や書面で暗証番号の変更を要求するといった対応を行ないました。（現在ではそのような暗証番号は設定できず撥ねられますが以前は違いました）
パスワードに関しても、ハッシュ化をしていなければ、特定のパスワードパターンの顧客で不正アクセスが増えた際に、個別にパスワード変更を依頼するという対応がとれるのです。
また、銀行ならば、不正に振込が行われた際に、顧客の過失割合を決める上で生のパスワードが必要になるでしょう。（顧客に、暗証番号やパスワードや、その管理についての過失がある場合、犯罪被害時の銀行による補償額が減額される約款になっている銀行が殆どです。）
Re:ハッシュ化にはデメリットもある (スコア:1)
その銀行は、自身から生パスワードが流出していないことを証明しなくてはならなくなりますよ。
これは、その銀行にとって詰みです。
生パスワードは、持っていること自体が巨大なリスクなのですよ。
Re:ハッシュ化にはデメリットもある (スコア:1)
生パスワードを保持していたからといって、銀行が、自身から生パスワードが流出していないことを証明しなければならない（ほぼ悪魔の証明）、ということにはならないと思いますが。
それを言い出したら、キャッシュカードでの不正引出があったら、銀行が、銀行から暗証番号が流失していないことを証明しないといけないのですか？
また、ハッシュ化していたところで、銀行またはシステム管理者の内部犯を疑いだしたら、ハッシュ化処理の前のパスワードを抜き出すことだって可能だし、ハッシュ化の際にソルトの使用やストレッチング処理を行っていれば、全顧客の生パスワードを解析するといったことは困難になりますが、特定の数人の顧客の生パスワードを、ハッシュ値からブルートフォースアタックで解析するぐらいのことは（よほど強いストレッチングをしていて、かつ顧客が強度の強いパスワードを設定していない限りは）現実的な時間で可能です。だからこそ、パスワードのハッシュ値が漏えいした企業が、顧客にパスワードの変更を依頼するケースが多いのです。（ハッシュ化は漏えいから悪用可能な状態となるまでの時間を稼ぐ役割）
ちなみに、銀行ではなく大手証券会社ですが、家族がマネックス証券のパスワードを忘れたときには、ログインID・口座番号・パスワード・暗証番号照会依頼書 [monex.co.jp]を郵送して照会しましたが、ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。このことから、マネックス証券は平文でパスワードを保存しているようです。
Re: (スコア:0)
別ACとして、おおむね納得しましたが。
キャッシュカードの不正利用は物理的に足がつきやすいですからねぇ。
> ログインID・口座番号・パスワード・暗証番号の全てが記載された紙が転送不要の簡易書留郵便で届きました。
暗証番号があり、全て同時に送っているのでアレですが、パスワードを「新規発行」したという可能性はゼロなんでしょうか。
# 某古参ISPもパスワード印刷してきたけどあれはどうだったか……
Re: (スコア:0)
Re: (スコア:0)
攻撃に使用されたと思われるものを網羅したハッシュリストを作って、それと照合じゃ駄目なんですかね？
攻撃側が有限なんだから(特に、辞書攻撃とかね)、それに対応するハッシュリストを網羅するのも別に無理って程ではないかなー、って思います。
Re: (スコア:0)
それは顧客のデメリットに更にデメリットを重ねさせて企業側のメリットとしただけに過ぎない。
Re:なぜ最大16文字？ (スコア:2)
表示した際の外観の都合上、その程度の制限が適切だと判断したとか、ありそうな無さそうな。
Re: (スコア:0)
いや、普通にやるでしょ。世の中そういうものです。
Re: (スコア:0)
世の中のサービスの多くはパスワードの文字数に制限あるけど、それが何か？
文字数制限あり→生パスワードを保存してる！はさすがに短絡的かと
Re:なぜ最大16文字？ (スコア:1)
この際、生パス管理してるからという理由があるのならまだ許せる。
無意味に16文字の制限を加えているのなら…その方がむしろ腹立たしい。
まあ生パスの話は置いといて、なぜ16までにしようと思うのだろう。
ちょっと足りない感がある人が多いと思うのだが。
Re:なぜ最大16文字？ (スコア:4, 興味深い)
小規模なシステムを管理していた際に、パスワードの文字数制限を255文字までとしていたことがありましたが、次のようなパスワードを登録する人が、あまりにも多かったです。
パスワードの文字数制限を12文字以下に制限するとこんな感じのが増えだしました。（"password"や単純な辞書に載っているものは登録段階で機械的にはじいているのでこれに含まれていません）
このように、文字数や文字種の制限が緩いと、メールアドレス（自分のものや友達・恋人の？）やURL（そのサイトや有名サイトなど）をパスワードに設定する人が出てくるのです。
理由は、たぶん、「英数字と記号を含めること」を推奨していたため、記号を含み、かつ記憶しやすい（コピペしやすい？）文字列としてメールアドレスやURLが思いつき、それをパスワードとしたのだと思います。
文字数の制限すると、きちんとしたパスワードっぽい文字列を登録してくれるユーザーが多くなるので、ある程度制限しているシステムが多いんだと思います。URLはスキーム名があるので良いですが、メールアドレスというのは自由度がかなり高いので、正規表現でメールアドレスのみを弾くのはなかなか大変です。従って、メールアドレスをパスワードとするのを弾きたい管理者は、文字数制限や、パスワードに"@"や"."の使用を禁止するという簡単な対策をとるのだと思います。（実在するドメインかどうかを検証する方法もありますが、面倒です）
余談ですが、パスワードをハッシュ化しているシステムだと、ユーザーが登録しているパスワードが見れないので、システム管理者がこういった傾向に気が付きません。
Re: (スコア:0)
URLをパスワードにするのか！なかなか良い案だ。
正直、ここまでの多様性があるのであれば、別に長いパスワードでも良いんじゃないでしょうか。
制限する理由にはならない気がします。
Re:なぜ最大16文字？ (スコア:1)
日本限定で仮名文字で17文字か31文字にして1q(季節)ごとに変更させるようにしたらいいかも。
#字余りには対応せず
みじかびのき(ゃ)ぷりきとればすぎち(ょ)びれすぎかきつらねは(っ)ぱふみふみ
Re: (スコア:0)
画像等の共有サービスで、パスワード認証はないけどURLが複雑怪奇なアドレスで、そのURLを共有したい人に教えてね、
っというやつは事実上そのURLが共通の認証パスワードという扱いですよね。
どっかからリンクを貼ったりしたら検索エンジンのクローラに晒されてしまいますが、
それはこの”パスワード”をWEBに公開しているってことですからね。
Re: (スコア:0)
そこまで考えて制限を設定したとは思えないけどなぁ。
それに、そんなバカなパスワードを設定するのも結局は自己責任だし。
文字数を制限することで、本当にセキュリティ目的に長いパスワードを設定したい人が設定出来なくなるのが問題だ。
バカにあわせるか、セキュリティ気にしぃにあわせるか。
パスワードは８〜１６桁もしくは３０桁以上にしてください。とかかなぁ。
AMCパスワードとwebパスワード (スコア:0)
＞なお、現行のAMCパスワード（数字4桁）は、引き続き「ANA予約センター」、「ANAマイレージクラブ・サービスセンター」へのお問い合わせ時や
＞各空港に設置の自動チェックイン機・SKY KIOSKなどで必要です。「Webパスワード」とあわせて「AMCパスワード」を管理いただきますようお願い申し上げます。
2個もパスワード覚えさせるとか利用者を混乱させるだけだろうに。
Re: (スコア:0)
さすがに新パスワードの郵送/メール対応じゃないか？