それは非常に悪いことです。すべてのユーザーデータはに保存する必要があり$_SESSIONます。または、検証Cookieを設定し、それを認証に使用する必要があります。
さらに、ユーザーのパスワードを「保持」しないでください。それをハッシュしてデータベースに保存し、ログイン時に投稿されたパスワードをハッシュと照合する必要があります。
さらに、ハッシュは一方向である必要があり、ユーザーの元のパスワードを取得または表示できないようにする必要があります。
最後に、MD5はひどく敗北しました。リモートでの安全性は失われ、レインボーテーブル攻撃によって破壊される可能性があります。bcryptのように、もっと強くて遅いもの（遅いのが良い）を調べる必要があります。
こんなことしないで
ここで、それをクリアしたので、説明させてください...
基本的に行っているのは、このデータを平文でユーザーに送信することです。トランスポートにSSL暗号化を使用している場合でも、それは依然として大きなリスクです。「ブラウザでのレンダリング」ではありませんが、それは問題ではありません。まだブラウザに送信されています。そして、この特定のケースで問題が発生しなかったとしても、構築するのは悪い習慣です。
md5()「でも、使っているのでパスワードがわかりにくいですよね？」と聞くかもしれません。
間違い。
はい、テキストは隠されています。ただし、隠されたバージョンのテキストをクライアントに配信してから、そのテキストをキーオフします。つまり、すべての人が見ることができる有効なパスワードをまだ表示しているということです。
パスワードが「correcthorsebatterystaple」の場合、誰かにパスワードが与えられるため、プレーンテキストで表示したくないでしょう。（実際、プレーンテキストで保存することすらしたくありません。どこにでも。サイト管理者として、パスワードのテキストを知りたくない、または見つける方法さえありません。可能であれば、他の誰かができます。）そうです。
したがって、代わりに、コードがパスワードとして解釈する「elughwelfguweliurgnswfglwerlgu」としてパスワードを隠します。だからあなたはそれを表示することができますよね？間違い。これで、クライアントからのパスワードとして「elughwelfguweliurgnswfglwerlgu」を受け入れることにより、「elughwelfguweliurgnswfglwerlgu」をシステムが受け入れるプレーンテキストのパスワードにしたためです。したがって、テキストを不明瞭にすることは何もしません。
つまり、いかなる形式のパスワードも決して誰にも渡さないでください。アプリケーションは入力としてパスワードを受け取る必要がありますが、出力としてパスワードを生成することは決してありません。
ダメダメダメ
アカウントを設定する（またはパスワードを変更する）ためにパスワードを入力する場合は、POSTとSSLを使用します。
それ以外の場合、パスワードは、URLにMD5またはプレーンテキストが含まれていない一方通行です。
ユーザーがログインしたら、セッションを提供します。これは期限切れになる可能性があるため、無効になります。
傍受されるように-あなたはただパケットスニファを手に入れることができます
これはどういうわけか悪意を持って傍受される可能性がありますか？
はい。誰でもあなたのページのソースを見て、ユーザー名とパスワードのmd5ハッシュを見ることができます。また、ページがユーザーにリダイレクトされるときに、ブラウザのURLにも表示されます。
中間者攻撃によって傍受される可能性はありますか？必ずしも。HTTPSを使用している場合、クエリ文字列は残りのリクエストとともにSSLパケットで暗号化されます。HTTPSを使用していない場合は、誰でもクエリ文字列を見ることができます。これにより、中間者攻撃を見るときにGETがPOSTと同じくらい安全になります。
HTTPS環境でGETの安全性が低下する可能性を比較すると、次のようになります。HTTPSクエリ文字列は安全ですか。