「おいAmazonがパスワード前方一致でログインできるぞ」

「おいAmazonがパスワード前方一致でログインできるぞ」
http://alfalfalfa.com/archives/395585.html


確かに,一致文字列以降をみない分,若干,弱くなってしまう.
パスワードが「hohoho」だったときに,一致文字列以降もみるパスワード・チェックであれば,「hohoho1」は拒否されるところを,Amazon のパスワード・チェック方式だと受理できてしまう.
もし,「普通の人は長い文字列を設定しておくだろうから,逆手にとって短い文字列にしておこう.そうすれば,長い文字列を試されたときに,全部はじかれるぞ,しめしめ」と思って短い文字列を設定している人がいるとしたら,クラックされやすそう.


これって,一般的なパスワード・チェック方式ではないんじゃないかなぁ?
というか,どういう実装をすれば,こうなるのだろう?
このチェックを実現するためには,パスワード文字列そのものが Amazon に保存されてないと実現できないよねぇ?
そうだとしたら,ちょっと,イヤだなー.あぶないなー.
少なくとも,よくある「パスワード文字列そのものは保存しない.パスワードを一方向変換関数に通したあとの文字列を保存する.チェックは,一方向関数を通したあとの文字列同士で行う.」という実装ではなさそう.


http://www.amazon.co.jp/gp/help/customer/display.html?ie=UTF8&nodeId=712602

お客様のアカウントの安全性を向上させるため、Amazonパスワードは大文字と小文字を区別できるようになりました。



"なりました"ってことは,前は区別していなかったということで... .
うーん,これは,パスワード文字列そのものを保存している気配が濃厚.
それって,チェックが弱くなる問題とは別の問題として,かなりまずいよーな.


うーん,こんなチェック方式でも,あんまり弱くならないのだろーか?

「総当たりでクラックされるときに,文字数の少ないほうを調べずに済み,かつ,一致文字列以降が間違っていてもよい」のだから,パスワードとして設定できる最大文字数が n文字で,パスワードとして使用できる文字種が k種だとすると,クラックするのに必要な最大の手間は,

普通は,
k + k^1 + k^2 ... k^n

Amazon 方式だと,
k^n ですむ.

差は,
n-1
Σ k^i
i
か.
あれ,そんなに減っちゃうの?
そんなに減っちゃったら,結構,弱くなるなぁ.
ということは,私が何か勘違いしているんだろうな.
だといいな.

眠いからねよー.










この記事へのコメント