« 無料版なんて要らなかった？ | メイン | Array/Dictionary バイナリ読み書き対応コミット »
2013年03月27日
Misc.:: ネットワーク認証
Tweet @jin1016をフォロー一般的なローカルのパスワード認証では、パスワードそのものを保存して比較するという方法はとらず、パスワードを一方向関数を通したものを保存し、認証時は入力されたパスワードを同じ一方向関数を通し、その出力結果を比較することで認証する。
つまり、パスワード自体は保存されていないし、パスワードでの比較も行われない。
一方向関数とは、入力から出力は求められるが、出力から入力は現時点では求められない関数。
ハッシュなどが用いられる。
以下、一方向関数は、ハッシュと書く。
ネットワークでの認証も基本的にはこれと同じ考え方。
当然のことながら秘密キーをネットワークで送るなんてことはしない。
コマンド+秘密キーをハッシュ通して、コマンドにそのハッシュ値を付与したものを送信すれば、秘密キーはネットワークに流れない(一般的に使われる HMAC-XXX などはもう少し複雑な計算をしている)。
認証側も同じように、秘密キーを加えてハッシュ計算する。
そして、ハッシュ値で比較すれば秘密キーが一致しているかどうかわかる。
ただ、この方法では不完全で、同じコマンドを送るのなら同じハッシュ値になるため、秘密キー関係なしに認証が通ってしまう。
そのため毎回ハッシュ値が異なるようにしなければならない。
異なるようにするには日時を入れればいい。
当然過去に使われた日時が使えると無意味(同じハッシュ値が使える)なので、最後に認証した日時よりも未来の時間でないと以後認証しないようにする必要がある。
つまり、いかにローカルの秘密キーを隠すかが鍵となる。
で、この 超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 記事の話。
TweetDeck は、そのまま秘密キーが保存されているから、バイナリ見れば見つけられる。
もふったーは、暗号化して保存されていたけど、実行時に複合化するから、実行時にメモリ見れば見つけられる。
強化版、デバッグ処理削除版ともに HMAC 計算部分にブレーク貼ってメモリ見れば見つけられる。
さらに強化した。
と言う流れの様子。
ネットワーク認証を行うにはここくらいまでは求められるということだろうか？
秘密キーの管理をユーザーにゆだねるのであれば、そこをどう隠すかは関係なくなるけど。
ただ、複合化のための秘密キーを隠すことになるか。
投稿者 Takenori : 2013年03月27日 23:12
comments powered by Disqus