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