アカウント名:
パスワード:
＃認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね
そのランダムコードをブルートフォース攻撃されたりして。
普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか
「普通」が重なってるよ。というのはさておき。
そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
それに、セッションIDがあるのに、わざわざ別にランダムコードを準備するのは普通なの？単にランダムコードって言うけど、実は乱数生成ってそんなに簡単じゃない。下手な方法を使うと、ブルートフォース攻撃どころか、予測攻撃すら成立しちゃうんだよね。なので、ランダムコードを自前で作るよりは、実績のあるセッションIDを元にプログラミングするのが、普通なんじゃないかと思うけど、どうかな？
＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
そうだよねえ。そもそもブルートフォース攻撃が一切受け付けない方法がより優れているのでは？まあ、セッションIDに対するものは可能性は残るわけだけど。
そう言ったつもりだったんだけど言い方おかしかったのかなぁ
言い方がおかしいね。元のコメントには、
認証後はランダムに作成された英数字をクライアントに渡し
で、「クライアントからのデータに関係なく」なんて内容ではないね。
＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？
細かいところに一々拘るのがプログラミングです。細かいところは適当に、ってのは、プログラムにはならないでしょう？セキュリティホールを生み出した人たちも「なんでそんな細かいところに拘るのかイマイチ解りませんが」とか言えば、「手打ちにして良い」なんてことになりますか？
すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。
謝罪には及ばないと思いますよ。ただ、esumi説がその程度のいい加減さだった、ということが判ったので、それで十分なんじゃないかと思います。
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。
いやいや。私の意見など、所詮実際に実装をしない素人の意見に過ぎませんよ。現実は、もっと厳しいって事です。もちろん、esumiさんが考えてるよりもっと、と言う意味でもありますが。
セッションの存続時間と、攻撃に必要な時間を天秤にかけて安全性を担保していることを理解していますか？
はい。理解しています。ランダムコードが十分に長ければ、被害は少なくなるとは思います。でも、そこを明らかにしておかないと、無意味とまでは言いませんけど、被害が出やすくなってしまいますね。そもそも、そのセッションと、そのセッションからアクセスできる口座番号を結びつけて管理しておくべきではないですか？#1970960 [srad.jp]では、ランダムコードの長さも、セッションと口座番号との関連付けも、言及されていませんね。
しかし、セッション云々と言うのなら、新たなランダムコードなんか必要ないとも思いますが。ユーザ対口座が1:nの関係だったとしても、その口座を切り替える処理があればいいような気がします。
理解しているかという質問はセッションIDにブルートフォース攻撃とはどういうことなの？という意味でしょう。
セッションIDにブルートフォース攻撃とはどういうことなの？
セッションIDへのブルートフォース攻撃は、ありえますよ。まともに生成されたセッションIDなら、その危険性は十分に下がるというだけです。それが、セッションとの関連が定かではない「口座番号等の情報」と関連付けられた「ランダムに作成された英数字 [srad.jp]」程度思い付きだと、どんな攻撃を防ぎ得るかも定かではありません。そもそも、セッションIDですらありませんしね。そんな面倒なことをするよりは、もっといい方法がありそうですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
どうしてこうなったか推理してみるテスト (スコア:2, 興味深い)
・が、時代の移り変わりと共に、セキュリティ・カードが導入されるようになり、認証は１度で済ますよう、途中で変更が加えられた
・その時深く考えずに認証後の口座情報引き出し部の仕様のみ従来のままで変更せず通してしまった
・気付かない ＞ ｵｱｰ
＃認証後はﾗﾝﾀﾞﾑに作成された英数字をｸﾗｲｱﾝﾄに渡し、その英数字と口座番号等の情報をログアウトまで一時的にｻｰﾊﾞ側で紐付け記憶させとけば良かったですかね
Re:どうしてこうなったか推理してみるテスト (スコア:1)
＃認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね
そのランダムコードをブルートフォース攻撃されたりして。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
Re:どうしてこうなったか推理してみるテスト (スコア:1)
普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか
「普通」が重なってるよ。というのはさておき。
そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
それに、セッションIDがあるのに、わざわざ別にランダムコードを準備するのは普通なの？
単にランダムコードって言うけど、実は乱数生成ってそんなに簡単じゃない。下手な方法を使うと、ブルートフォース攻撃どころか、予測攻撃すら成立しちゃうんだよね。
なので、ランダムコードを自前で作るよりは、実績のあるセッションIDを元にプログラミングするのが、普通なんじゃないかと思うけど、どうかな？
＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
そうだよねえ。そもそもブルートフォース攻撃が一切受け付けない方法がより優れているのでは？
まあ、セッションIDに対するものは可能性は残るわけだけど。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
そう言ったつもりだったんだけど言い方おかしかったのかなぁ
＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？
Re:どうしてこうなったか推理してみるテスト (スコア:1)
そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
そう言ったつもりだったんだけど言い方おかしかったのかなぁ
言い方がおかしいね。元のコメントには、
認証後はランダムに作成された英数字をクライアントに渡し
で、「クライアントからのデータに関係なく」なんて内容ではないね。
＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？
細かいところに一々拘るのがプログラミングです。細かいところは適当に、ってのは、プログラムにはならないでしょう？
セキュリティホールを生み出した人たちも「なんでそんな細かいところに拘るのかイマイチ解りませんが」とか言えば、「手打ちにして良い」なんてことになりますか？
Re:どうしてこうなったか推理してみるテスト (スコア:1)
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。どうぞ拘りを持って気が済むまでどうぞ。
＃どうせ堅いレスが入ってるんだろうなぁと思い、嫌になった為見返すのが遅くなり真に申し訳ありませんでした
＃もっとも回答を遅らせた以外については全く悪いとは思ってませんが
Re:どうしてこうなったか推理してみるテスト (スコア:1)
すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。
謝罪には及ばないと思いますよ。
ただ、esumi説がその程度のいい加減さだった、ということが判ったので、それで十分なんじゃないかと思います。
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。
いやいや。私の意見など、所詮実際に実装をしない素人の意見に過ぎませんよ。現実は、もっと厳しいって事です。
もちろん、esumiさんが考えてるよりもっと、と言う意味でもありますが。
Re: (スコア:0)
セッションの存続時間と、攻撃に必要な時間を天秤にかけて
安全性を担保していることを理解していますか？
Re:どうしてこうなったか推理してみるテスト (スコア:1)
セッションの存続時間と、攻撃に必要な時間を天秤にかけて安全性を担保していることを理解していますか？
はい。理解しています。ランダムコードが十分に長ければ、被害は少なくなるとは思います。でも、そこを明らかにしておかないと、無意味とまでは言いませんけど、被害が出やすくなってしまいますね。
そもそも、そのセッションと、そのセッションからアクセスできる口座番号を結びつけて管理しておくべきではないですか？
#1970960 [srad.jp]では、ランダムコードの長さも、セッションと口座番号との関連付けも、言及されていませんね。
しかし、セッション云々と言うのなら、新たなランダムコードなんか必要ないとも思いますが。ユーザ対口座が1:nの関係だったとしても、その口座を切り替える処理があればいいような気がします。
Re: (スコア:0)
理解しているかという質問は
セッションIDにブルートフォース攻撃とはどういうことなの？
という意味でしょう。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
セッションIDにブルートフォース攻撃とはどういうことなの？
セッションIDへのブルートフォース攻撃は、ありえますよ。まともに生成されたセッションIDなら、その危険性は十分に下がるというだけです。
それが、セッションとの関連が定かではない「口座番号等の情報」と関連付けられた「ランダムに作成された英数字 [srad.jp]」程度思い付きだと、どんな攻撃を防ぎ得るかも定かではありません。そもそも、セッションIDですらありませんしね。
そんな面倒なことをするよりは、もっといい方法がありそうですよね。
Re: (スコア:0)
それがまさにセッションID。