パスワードを忘れた? アカウント作成
10814800 story
セキュリティ

パスワードを管理する新しい手法「PolyPassHash」が提案される 17

ストーリー by hylom
でもパスワード使い回しには無力 部門より
あるAnonymous Coward 曰く、

パスワードの管理において、「PolyPassHash」と呼ばれる新しい管理手法が提案された(slashdot論文PDF)。

この手法が提案通りに機能するならば、個別のパスワードを対象としたクラッキングがほぼ無効化されるようだ。またサービスを利用するユーザー側でなにかを変更する必要はなく、パスワードを保存・管理する側(サービス提供側)でこの手法を採用すればいいだけとのこと。

すでにCおよびPythonによる実装も公開されている。

安全性の高さの説明として、「6文字のランダム文字列のパスワードが3アカウント分あったとして、salt+なんらかのhashで保管されている場合は3つのパスワードすべてをクラックするのに1台のノートPCで1時間ほどの時間しかかからなかったが、 PolyPassHashで保管した場合は地球上の計算機資源をすべて使って宇宙の終わりまでアタックしてもクラックされることはない」とある。

PolyPassHashでは、パスワードのハッシュ値を単純に保存するのでは無く、Adi Shamir氏が提案した秘密分散法に基づいて分割・分散して保存することでセキュリティを高めるという。これにより、攻撃者は複数のパスワード群に対し同時にクラックを行わなければならなくなり、その困難さが大きく向上するという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by fuchikoma (2044) on 2014年04月08日 10時48分 (#2577611)

    パスワードの管理の歴史が簡単に書かれつつ、以下のような論旨が展開されていた。

    「パスワードを平文で保存するのヤバくね?」
    →「パスワードを一方向ハッシュ関数でハッシュしようぜ!」

    「ハッシュ化されたパスワードも最近のPCだと割と簡単にクラックされるようになってきてね?」
    →「ハッシュ化されたパスワードを格納している場所(ファイル/DB)を暗号化しようぜ!」

    「ハッシュ化されたパスワードを格納している場所を暗号化しても秘密鍵が漏れたら意味なくね?」
    →「秘密鍵を Threshold Cryptography で分散管理しようぜ!」 (ここが PolyPassHash の発想)

    で、この Threshold Cryptography というやつは、例えば RAID で言うところの RAID5 的な感じで「何個か valid な情報が揃えば元の情報を完全に復元できる」というテクニック。
    PolyPassHash では「登録されているパスワード全体のうちの数個のパスワード」をあらかじめ指定しておいて、そいつを threshold に使う・・・のかな?(自信なし)
    だから PolyPassHash を使うシステムを再起動する時には、再起動直後の最初の段階で threshold なパスワード(を持たされているアカウント)が閾値に足りるだけ正しく入力されないと、全体が使えない。と書いてある。ように読める。

    あとは誰か識者の解説を待ちたい。

    • 色々しっくりこない点もありますが

      - パスワードのハッシュと論文で言うところの"Share"と呼ばれる鍵を使って計算した値を各ユーザ毎にDBに保存する
      - Shareは盗まれないようにどこにも保存しない
      - DBが盗まれてもShareがわからないのでオフライン攻撃でも果てしない時間がかかる

      がポイントになのかと思います。

      重要なのはShareです。

      ShareはPolyPassHashが有効な認証システムの初期化時に生成されて、閾値としてカウントされるアカウントを作成したら捨ててしまう。
      閾値分のパスワードが入力されるまで一般ユーザに対しては認証を受け付けない。
      閾値分の正しいパスワードを入力することで、Shareを求めることができる。具体的には、シャミアの秘密分散法を使う。得られたShareはメモリ上でしか保存されない。
      それ以降の普通のユーザ認証は、入力されたパスワードに対してソルトでハッシュ化して、さらにShareを使って計算した値がデータベースに保存されている値とマッチするかどうかで行う。

      使われている手法はどれも昔からあるもので、それらを使って低コスト(ユーザ側変更なし、追加ハードウェア必要なし)でセキュリティの高いパスワード管理ができるようになるというのがウリのようです。

      親コメント
  • これはもうどうしようもないんだろうか。

    --
    屍体メモ [windy.cx]
    • by Anonymous Coward on 2014年04月08日 8時52分 (#2577522)

      「良く使われるダメなパスワード」を入力することで簡単に突破できることには変わりないと思う。

      親コメント
    • by Anonymous Coward
      …逃がさん…お前だけは…
    • by Anonymous Coward

      要件としては、

      • 人間が機器類に頼ることなく記憶可能であり、
      • 多種多様な(少なくとも何百兆通り以上の)選択肢が存在しうるもので、
      • 客観的に間違いのない差異を検出できるもので、
      • コンピュータ上でデータとして表現(再現)可能なもの

      ってところでしょうか。上記の要件からすると、何よりも文字という選択肢が安直かつ堅牢という結論になりそうですが・・

    • by Anonymous Coward

      今のところ、個人と不可分で本人の意思に反する取り出しが最も困難なのが記憶と思われる。
      その記憶で再現性の高いのがワード。
      JMとかあるけど画像とかだとちょっと難しいと思う。

      • by Anonymous Coward

        今のところ、個人と不可分で本人の意思に反する取り出しが最も困難なのが記憶と思われる。

        なるほど。確かに画像認証や指紋だと、何か薬を飲まされたりした場合突破される危険性がありますね。
        記憶というのはそう考えると一番安全な保管方法なのかも。過去の黒歴史やスラドに投稿してしまった痛々しいコメント、まだ青かった自分が書いた糞コードなどなど……

  • by Anonymous Coward on 2014年04月08日 7時52分 (#2577484)

    この技術が本物だとしても、一部のサービス提供者がこの技術を利用せずにパスワードを流出させるだけでリスト型攻撃はある程度効いてしまうんじゃないでしょうか。
    端からパスワードをハッシュで保存してるようなサービス提供者ならこういう技術の導入も進むだろうけど、未だに平文で保存してるような所だと何もしないですよね。

    つまり、利用者側がサイト毎にパスワードを変える等の対応は引き続き必要って事で、本当に何も変わってないですね。

    • by Anonymous Coward on 2014年04月08日 9時08分 (#2577529)

      要するに、導入すれば暗号データが流出しても解析は無理=全事業者がこうすれば、流出を心配する必要がなくなるよ、という話で。
      という前半は同じなんですが、後半が個人的な感覚と違いました。
      多くのアカウントを持つ事業者だけでも導入すれば、そこには他へ使い回ししてる人も多く含まれるだろうから、未導入の事業者で得られた少ないペアを他の事業者へ転用しても同一アカウントが少ない=成功率が減るんじゃないかと思います。
      まあ、それでも運悪く当たりになる人はいるわけですが。

      親コメント
  • by Anonymous Coward on 2014年04月08日 8時59分 (#2577527)

    ログインして照合するときは全部必要になるわけだから、結局は1台に全部保管、面倒だからアクセス権も全部同じだったりして。

    • by Anonymous Coward

      別に、複数ファイルに分散するという意味じゃないからね。
      論文のタイトルや冒頭の数行を読むだけで、パスワードファイルが全部入手された場合を想定しているのがわかる。

  • by Anonymous Coward on 2014年04月08日 8時14分 (#2577493)

    どういう仕組みなの?

  • by Anonymous Coward on 2014年04月08日 9時26分 (#2577537)

    これで安心してAPOPを使いまくるぞ!

  • by Anonymous Coward on 2014年04月08日 9時49分 (#2577566)

    自分だけが強固なパスワードを用意してもヒッ包められた何人かがお気楽パスワードだったら
    登録時の不公平を引き摺るのかな?
    パス変更する生活時間とかIP地域とかを気にする必要が

  • by Anonymous Coward on 2014年04月08日 20時33分 (#2578124)

    PolyPassHashが流行らないほど、PolyPassHashは堅牢でしょう。

typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...