アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
ステートフルなWebアプリ？ (スコア:0)
いわゆる「ステートフルなWebアプリ」な
開発形態やFrameworkが普及すると、
このてのミスも減ってくる、のではないでしょうか？
というのは、こういう
「見せないけど実はHTMLに紛れさせてる情報」の類を
サーバ側のステートの一部として
容易に管理できるようなアプリ構成/FWになっていれば、
わざわざそれをHTMLにも書き出そうなどと思う人はいなくなるだろうから、です。
GUIアプリを作ってたころ、
パスワとかを変数に格納することはあっても、
それを必要もないのにGUIコ
Re: (スコア:1, 参考になる)
＃元コメントの人は、WEB関連の開発をしたことがないのでしょうけど
＃何でこんな話が無くならないのかは、HTMLを使って認証機能を作ってみるのがいいですよ
＃HTMLやブラウザやURL（URI）にパスワードとIDを保存しないまま、画面が変わる度にどうやって
＃認証し、セッションを維持するのか等、面白い経験を出来ますよ。
＃
＃単体アプリケーションならIDとパスワードなんて認証が終わったら捨ててもいいかもしれないデータですしね。。。
Re:ステートフルなWebアプリ？ (スコア:0)
それをクッキー（inputのhiddenでも別によさげ）にでも保持させると思います。
これだと問題はあるのでしょうか。
Re:ステートフルなWebアプリ？ (スコア:1, 参考になる)
その場合だと再送攻撃対策としてhttps必須だよね。
普通はハッシュだけでなく多層に防衛策を講じるよね。
Re: (スコア:0)
で、要件に合わせてより高度に暗号化という感じで。
Webセキュリティの常識みたいなものって、
あまり教わる機会がなかったりしますね。
Re: (スコア:0)
Re: (スコア:0)
どれくらいセキュリティ的に強くなるんですか?
ほとんど変わらない気がしますが。
Re: (スコア:0)
Re: (スコア:0)
単純にHTMLのソースやCookieを見てもパスワードがわからない、
という効果があるね。
Re: (スコア:0)
ハッシュされたパスワードをクッキーに入れておいて、
セッション毎にそれをサーバ側のパスワードをハッシュしたものと
比較することで認証すると言っているのだから、事実上、
パスワードを流しているようなものなんだよね。
そのハッシュ化されたパスワードを盗んで、クッキーに入れれば
第三者がアクセスできるよね。
他の人がコメントしてるように、同じパスワードをあちこちで使った
ときに、別のサイトのパスワードまでは盗まれないという効果しか
ないんじゃないかな。
ランダムな文字列を使ったセッションキーを認証後に発行して
クッキーに食わせておいた方が、パスワードをハッシュしたモノを
食わせておくよりナンボかましだと思う。
ちゃんとsrc ipaddrは覚えておいて、かつキーもちゃんと削除
しないとだめだし、最初の認証でパスワードを盗まれたら同じだけど。
Re: (スコア:0)
といいたかっただけなんで、おおむね同意です。
Re: (スコア:0)
これだと盗み見られても正規の手段（ログイン画面でパスワード入力するとか）で成りすまされることはない。
それに同じパスワードを複数箇所で使用していたとして、その内一つから漏れても軒並みアウトにはならない。
また盗聴対策でTSLを使っても生パスワードをサーバに送る以上サーバロジック上は見えるのだから、通信中でなくサーバ上で盗まれる可能性は残る。ハッシュ値だと盗まれても生パスワードは知られることはない（はず）
サーバからクライアントならばそもそも論外。