1

パスワードの保存、ハッシュ、ソルティング、「ペッパー」、MAC などについてよく読んでいます。新しい Web サイトとセキュリティを作成しようとしているからです。セキュリティは私にとって本当に重要ですが、検討している理由がいくつかあります現在は関係のない Google 認証 (または Facebook、OpenID など) を使用していませんが、ここまで来ました。

私は Google App Engine を初めて使用します。これが私の最初のプロジェクトになる予定です。「インスタンス時間」と、「CPU 時間」ではなく前述のクォータがあることについて少し混乱しています。さらに悪いことに、インスタンス時間の無料クォータが何であるかを理解できませんでした。

これが私がクォータについて心配している理由と、それが私のセキュリティ上の懸念と何の関係があるのか​​ということです: 私があちこちで読んだ 1 つの推奨事項は、複数の反復を行い、パスワードを数回ハッシュすることです。はるかに多くの時間（数字はありませんが、https://security.stackexchange.com/のどこにでもあります）。

複数回の反復は CPU 時間に直接影響します。GAE に CPU 時間のクォータがある場合、ユーザーがログインするたびに 1000 回の反復を行うことは問題になる可能性があると思います。 15分後まで、GAEクォータドキュメントで読むと次のとおりです。

通常、インスタンスの使用量は、インスタンスの稼働時間に基づいて時間単位で請求されます。課金はインスタンスの起動時に開始され、インスタンスのシャットダウンから 15 分後に終了します。Admin Console の [パフォーマンス設定] タブで設定された最大アイドル インスタンス数までのアイドル インスタンスに対してのみ課金されます。ランタイム オーバーヘッドは、インスタンス メモリに対してカウントされます。

つまり、ユーザーがログイン (1000 回ハッシュ) した場合、サイトを引き続き使用すると、インスタンス時間は、全員がページを離れるまで + 15 分になりますか? これが本当なら、1000回繰り返しても、ユーザーがログインするのに「余分な」時間がかかることを除いて、割り当てに大きな影響はありませんが、私はそれを認識しており、それは価格です喜んで支払います。

私が行う反復の回数は、ユーザーがログインする時間を許容できるものにし、知覚できないものにするため、これについて心配する必要はありません。

私の質問は次のとおりです。

  1. 多くの反復を行うと、インスタンス時間に直接影響がありますか、またはインスタンス時間の合計方法に関する私の仮定は正しいですか?
  2. Google App Engine に CPU 時間の割り当てはありますか? 無料クォータはありますか?
  3. インスタンス時間の無料クォータとは何ですか?

答え:

  1. Moishe が回答を受け入れ、彼が尋ねた他の質問を見てください (回答はありませんが、有益なコメントがあります) 。 App Engine スケジューラはいつ新しいスレッドと新しいインスタンスを使用しますか?
  2. Google によると、CPU 時間の割り当てはありません: http://googleappengine.blogspot.com.es/2009/02/skys-almost-limit-high-cpu-is-no-more.html
  3. ここで質問番号 3 に対する回答を見つけました: Google App Engine Frontend Instance Hours Limit Reached
4

3 に答える 3

1

インスタンス時間は、サーバーが実行されている間、リクエストに応答している間などです。サーバーが実行されていない場合、リクエストなどで起動することはできません。

インスタンス時間をコンピュータの電源が入っていると想像してください。オフのときではなく、オンのときに課金されます。

複数のインスタンスを持つことができるので、インスタンスが 2 つあるとします。インスタンス時間が 2 倍になります。

インスタンスがオンの場合はインスタンス時間のみが発生し、オフの場合はインスタンス時間は発生しませんが、ハッシュも発生しないため、パスワードのハッシュはこれに影響しません。

于 2012-07-17T13:24:33.190 に答える
1

リクエストの処理に時間がかかる場合。たとえば、非常に計算量の多い作業を行っていて、他のユーザーを長時間待たせたくない場合、App Engine スケジューラはアプリケーションの別のインスタンスを起動して、着信リクエストを処理することがあります。

パスワードのハッシュの計算に 1 分かかり、その 1 分の間にアプリケーションが別のユーザーからリクエストを受け取るとします。そのユーザーは、リクエストに対するレスポンスを得るまで 1 分待つことができます。または、App Engine スケジューラが別のインスタンスを起動してそのリクエストを処理し、レスポンスをはるかに早く返すことができます。管理コンソールの [アプリケーション設定] ページの [パフォーマンス] スライダーを使用して、別のインスタンスが起動するかどうかを調整できます。

基本的に、インスタンス時間について尋ねる必要がある質問は、重複するリクエスト (つまり、現在のリクエストが完了する前に新しいリクエストが来る) を受け取る可能性があるかどうかです。これが頻繁に発生し、ユーザーに迅速な対応が必要な場合は、より多くのインスタンス時間の予算を立てる必要があります。

実行する必要がある大規模な計算は、リクエストごとではなく、たとえば Cookie を生成するための最初のサインイン時にのみ、頻繁に行われることはないと思います。

質問 #1 に明示的に答えるために、多くの反復を行っても、リクエストの重複が発生した場合にのみインスタンス時間に影響します。30 秒ごとに 1 つのリクエストのみを取得する場合、各リクエストの処理 (各ハッシュの計算やその他の操作の実行を含む) に 30 秒を費やすことができ、インスタンス時間の無料クォータを超えることはありません。逆に、1 秒あたり 10 件のリクエストを受け取り、リクエストの処理に 100 ミリ秒以上を費やすと、インスタンス時間をかなり早く超過し始めます。

于 2012-07-17T15:08:48.377 に答える
0

パスワードに関する情報源は複数あります。マルチパスハッシュを奨励するものを読んだことがあるでしょう。この決定を確定する前に、以下の最初のリンクを検討してください。このページからの抜粋: 「結果がより安全になることを期待して、さまざまなハッシュ関数を組み合わせようとするのは簡単です。ただし、実際には、それを行うメリットはありません。相互運用性の問題が生じるだけです。また、ハッシュの安全性が低下することさえあります。」

考慮すべき2つの貴重なリンク（1つ目は上記の引用、2つ目は適切な「ハウツー」ソースです）：

http://crackstation.net/hashing-security.htm

http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes

于 2012-07-18T17:19:39.227 に答える