私はSocket.IOを実行しており、mysqlクエリ（jsで実行）を介してユーザ名とパスワードを確認するサーバー部分を持っています。私の質問は：クライアントのユーザー名/パスワードをクライアントのjavascriptからサーバのjavascriptファイルに安全に送ることは可能ですか？ユーザーがパスワードを確認することはできませんか？パスワードはすでに（PHP経由で）ハッシュされていますが、私はハッシュを持っていて解読できないようにしたくありません。安全に別のjavascriptファイルにユーザ名/パスワードを渡す
//編集
さらなる議論の後、私は常駐するスクリプトのほかにどこでもハッシュされたパスワードを送信するために悪いです同意します。ユーザーを一意に識別し、javascriptを介してそれらの変数を渡す別の方法はありますか？私のサーバーjsファイルはパスワードなしで認証できますか？
ユーザ認証が行われる典型的な方法の1つは、ユーザがSSLを介してusername/pwdを提供することです。これはサーバー上の資格情報と比較されます（説明したように、しばしばハッシュアルゴリズムを使用します）。資格情報が確認されると、サーバーはそのユーザーのセッションIDを作成します。セッションIDは、サーバーのどこかに一時的に格納され、クッキーによってクライアントに返されます。以降のすべてのWeb要求は、このユーザーに対して有効なセッションIDがCookieに含まれていることを確認します。もしそうなら、それは正しいユーザーです。
セッションIDはユーザーの実際の資格情報とは無関係であり、セッションIDでユーザーの資格情報に長期間のリスクがないように、ユーザーがログインするたびに異なる必要があります。その代わりに、セッションIDは、ユーザー資格情報を正しく提供したブラウザに発行された一時的なトークンに過ぎず、サーバーは（後続のページ要求で）これらの要求が「ログイン」ユーザーからのものであることを知ることができます。
セッションIDが盗まれた場合（中間者詐欺など）、セッションIDを持つ人は誰でもアカウントに一時的にアクセスできます。したがって、セッションIDを保護する必要があると思われる場合は、初期認証とセッションIDを使用する後続のすべてのページアクセスにSSLを要求する必要があります。
セッションIDは一時的なもの（一定期間後に期限切れになる可能性があります）で、サーバーは認証されたセッションの指示としてこれ以上受け入れないことによって、いつでも取り消すことができます。この点で、セキュリティで保護されたログインを繰り返すインジケータとして、実際の長期的な資格情報を使用するよりもずっと簡単で安全です。
あなたの所在地がわかりました。だから、もし私がjavascript経由でセッションIDを渡すなら、どうすればMySQLと照合することができますか？私はsession_idのフィールドを追加し、ユーザーがログインするたびにDBに保存することができると思いますか？または、これを処理するより良い方法はありますか？ –
@EdR - セッションIDをサーバーに保存する方法はあなた次第ですが、どのような方法が最適なのかは、アプリケーションの実装に大きく依存します。これをDBに格納することは、おそらくこれを処理する最も簡単な方法です。注意してください。どのように保存するかによって、特定のユーザーに対して複数のセッションが同時に生存できるかどうかが影響を受ける可能性があります。 – jfriend00
それをDBに保存するのは大丈夫です - あなたはそれぞれのページビューごとにあなたのDBを照会しますが、おそらくすでにそうです。あなたは非常に簡単にmemcachedの種類とDBからこれを移動することができます。 – Konerak
ハッシュを解読すると、才能を発揮します。 – alex
私は、ハッシュが何であるかを知ることができるという私の考えは、私の意見ではセキュリティ上のリスクがあると考えていますが、私はphpでsaltでsha512ハッシュを使用しています。 –
ユーザーが独自のハッシュを知っているのは悪いことではありませんが（結局のところ、各ハッシュはユーザーごとに一意の塩で塩害します）、このハッシュを渡すのは悪いことです。あなたがセキュアなチャネルHTTPSを通過させない限り。 – Konerak