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