2012-08-07 15 views
7

私は、ユーザーが登録できるPHPサイトをプログラミングしています。登録ユーザーと未登録ユーザーの両方が、それぞれのユーザー名とパスワードを入力できます(例:smith8h4ft-j9hsbnuio)。PHP - 他のサイトのユーザー名とパスワードを暗号化する

私のPHPスクリプトは、$_POSTという変数を送信し、マークページをダウンロードして解析し、 marksDB = Array("subject" => Array("A", "B", "A", "C"), ...)という配列を作成し、それを再フォーマットして書き込みます。

私の質問は: 私はどのようにユーザー名とパスワードを安全に保つ必要がありますか?

私は現在、ユーザー名とパスワードを忘れてmarksDB$_SESSIONに入れています。ユーザーがたとえば30分、marksDBが削除されます。これらのデータはどれくらい安全ですか$_SESSION?また、ログインしてページを一度表示してからもう一度表示しないようにするため、スクリプトはセッションからmarksDBを削除しませんか?セッションは自動的に削除されますか(gc.maxlifetime)?

登録ユーザーについてはどうなりますか?私はあらゆるものを安全にしたいと思っていますが、30分ごとにパスワードを入力する必要はありません。 hereのようにクレデンシャルを暗号化するのは安全ですが、3番目のユーザパスワードはありませんか?または、毎回パスワードを尋ねるようにしてもいいですか?

EDIT:迅速な回答のため

おかげで、
@Justinᚅᚔᚈᚄᚒᚔ:私は、彼らはいくつかのAPIを持っている疑いが、私は念の
@Abidフセインのために、それらを求めることができます非常に便利なリンクをありがとう。 (両方ともお返事ありがとう)。
私はユーザーの資格情報を捨てて、markDBだけを解析しました。ログアウトまたは非アクティブの後で、おそらく捨ててしまいます。

+0

唯一の大きなリスクは、セッションハイジャック、IMOです。特権が変更されたときにセッションIDを再生成することができます。 – Leri

答えて

2

学校のサイトでAPIが公開されていない場合(たとえば、using OAuth like the StackExchange sites do)、オプションは限られています。

一般に、は、ユーザーの平文の資格情報を絶対に必要以上に長く保管することは絶対に避けてください。あなたがそれをしようと想像する可能性のある方法(セッションハイジャック、盗難された鍵、復号化など)にはセキュリティ上の意味があります。

より良い方法は、マークのダウンロードプロセスを厳密にユーザーが開始するようにすることです。それらに「自分のマークを検索する」というボタンを付け、そこで認証プロセスを行ってマークをダウンロードし、その資格情報を捨てます。彼らが "同期する"たびに、彼らは認証する必要があります。マークが頻繁に定期的に変更されない限り、必要なすべての情報を一度にダウンロードして、後で使用するためにサーバに安全にキャッシュすることはできません。

0

セッションファイルはサーバー側であるため、クライアントには見えないようにする必要があります。しかし、セッションIDを知っていれば、あなたのプログラムは別のセッションを使用するように依頼することができます。あなただけが知っているキー(多分新しいものは、ユーザーごとにランダムに生成され、保存された)

+1

いいえ。パスワードを*暗号化するべきではありません。あなたは*ハッシュ*する必要があります - あなた自身のアプリケーションでさえそれを元に戻すことはできません。 –

+0

@AndrewBarberしかし、同じハッシュを使用しない限り、どうやって他のサイトに送ることができますか? –

+1

あなたはちょうどあなた自身の質問に答えました。 –

0

セッションファイルとそれを暗号化した後、あなたがDBにパスワードやファイルを保存することができ、登録ユーザの場合は

特定の時間が経過するとガベージコレクタによって削除されますが、_SESSIONに格納するための経験則は、画面に出力するデータのみを格納します。つまり、パスワードはセッションに保存するものではありません。セッションファイルはサーバーから読み取ることができ、悪意のあるユーザーがセッションをハイジャックして、見ていないとか、何とかしてvar_dump($_SESSION)と表示されているものを見ることができます。

登録ユーザーに長いセッションを許可したい場合は、定期的なページリフレッシュをJSで行うことができます(ページを更新するだけでなく、非同期リクエストでも可能です)。あるいは、可能であればセッション時間をini_setに増やすこともできます。 は必ずしもであり、パスワードを繰り返し尋ねるのは安全ではありません。あなたが求めているときにパスワードの脆弱性に依存します。

別の解決策は、悪意のある「Remember Me」Cookieを使用してユーザーをログインさせ続けることです。

パスワードは解読用ではありません。秘密のために暗号化する。認証のためにハッシュ。

0

セッション内のすべてがサーバー側であるため、他のユーザーはアクセスできません。ただし、説明されているように、セッションは「ハイジャック」される可能性があります。here

PHP.iniでセッションの長さを長くしたり、バックグラウンドで定期的なAJAX呼び出しを使用してセッションを有効にすることができます。セッションがサーバーによって期限切れになると、セッションは削除されます。

パスワードを暗号化して復号化できるようにすることは、通常、代替手段がない限り嫌になります。暗号化を使用すると、あなただけでなく、データベースやソースコードにアクセスできるすべてのユーザーがパスワードを取得できます。

1

参照URL

http://phpsec.org/projects/guide/4.html

http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/

http://talks.php.net/show/phpworks2004-php-session-security

http://segfaultlabs.com/files/pdf/php-session-security.pdf

safest way to create sessions in php

も読んでください

セッションは、クッキーよりもはるかに安全です。しかし、セッションを盗むことはまだ可能であり、そのため、ハッカーはそのセッションにあるものすべてに完全にアクセスできます。これを避けるためのいくつかの方法は、IPチェック(かなりうまくいくが、非常に低いので、それ自身では信頼できない)とノンスを使うことです。一般的にノンスでは、ページごとに「トークン」があるので、各ページは、最後のページのノンスと、それが保存したものと一致するかどうかをチェックします。

いずれのセキュリティチェックでも、使い勝手が低下します。 IPチェックを行い、そのユーザーが固定IPを保持していないイントラネットのファイアウォール(またはこれを引き起こす他の状況)の後ろにいる場合、IPを失うたびに再認証する必要があります。ノンスで、あなたはいつも楽しい "クリックするとこのページが壊れる"という状況が発生します。

しかし、クッキーを使用すると、ハッカーは簡単なXSS技術を使用するだけでセッションを盗むことができます。ユーザーのセッションIDをCookieとして保存すると、これも脆弱です。したがって、サーバーレベルのハッキングを行うことができる人にはセッションが忍耐強くても(サーバーが安全であれば、より洗練された方法と通常はいくらかの特権が必要になります)、さらに何らかのレベルの検証が必要になります各スクリプト要求時にクッキーとAJAXを一緒に使用するべきではありません。これは、クッキーが盗まれた場合、町に行くのが簡単になります。たとえば、ページでnonceが使用されていてもページが再ロードされない場合、スクリプトは一致するものだけをチェックしている可能性があります。そして、クッキーが認証方法を保持しているなら、今度は盗まれたクッキーとAJAXの穴を使って町に行くことができます。

関連する問題