1

userというテーブルがあるとしたら、データベースをどのように設計しますか。

User_Table:id, username, password, password_salt, email, email_salt

ログインに失敗した回数と最後にログインに失敗した回数をどこに保存しますか?

total_failed、last_failed_login_time

彼らのメールアドレスが検証されているかどうかも記録したいですか?

これを行うための最良の方法(多くの結合を使用するため、必ずしも正規化されているとは限りません)は何でしょうか?何を指示してるんですか?

4

5 に答える 5

2

私は保存total_failedlast_failed_login_timeますUser_Table。ログインに失敗した場合はいつでも更新できます。email_validatedそこにも保管できると思いますが、それが何を意味するのか正確にはわかりません。

于 2011-02-14T18:26:37.957 に答える
1

total_failedとはどちらもlast_failed_login_time保存するのにかなり奇妙なフィールドです。通常、ログインの失敗は、システムへの攻撃を検出するために使用されます。

しかしTotal failed、一般的なユーザーはパスワードを誤って入力することがあるため、特定のユーザーがシステムにアクセスしている時間と頻度の大まかな尺度になるまで、時間の経過とともに単純に忍び寄るわけではありません。したがって、このフィールドの数値が大きいと、あまりわかりません。

Last_failed_login_time興味があるかもしれない以前のデータを一掃するので、あまり授与しないようです。

たぶん私はこのデータを追跡するポイントを逃していますか?

于 2011-02-14T18:45:51.147 に答える
0

これらのフィールドの両方をユーザーレコードの一部として保存できます。正規化されていない(とにかく、5NFに正規last_failed_login_time化されている)唯一のことは、 null許容にする必要があるという事実です。

同じことが。にも当てはまりますemail_validated。行の一部として保存できます。

于 2011-02-14T18:29:33.230 に答える
0

まず、この種のロギングは、包括的なセキュリティ監査の一環として、オペレーティングシステムによってより適切に実行される可能性があります。

データベース設計の観点からは、ユーザーテーブルへの保存total_failedlast_failed_login_timeユーザーテーブルへの保存に問題はありません。しかし、ネットワーク管理者の観点からは、あるかもしれません。

ログインの失敗は、クラッキングの標的になっていることを示している可能性があります。ネットワーク管理者として、私はむしろ成功したログインと失敗したログインの両方の数と分布(時刻ごとの数)を監視したいと思います。そのためには、それらを別のテーブルに保存する必要があります。

于 2011-02-14T18:46:03.400 に答える
0

このデータに要約列を使用する代わりに、代わりにログイン試行テーブルを実装することをお勧めします。

ユーザー名、ログイン試行が行われた日付、そのログイン試行のステータス(成功、パスワードが正しくない、不明なユーザー名など)、および試行自体に関連するその他の関連情報を追跡するテーブルを作成できます。不明なユーザー名を使用しようとするとユーザーIDがNULLになるため、(試行された)ユーザー名を含める必要があります。

この構造により、必要な情報だけでなく、その他のセキュリティ、監査、および統計レポートを取得できます。

于 2011-02-14T19:18:07.213 に答える