Quels sont les champs que la table utilisateur doit contenir du point de vue sécurité/authentification?

Question

Lors de la conception table utilisateur quel serait le doit avoir des champs du point de vue authentification de sécurité/utilisateur pour une application Web (.NET et SqlServer 2005)

Je suis venu avec les champs suivants:

userID 
username -- preferably email 
passwordHash 
onceUsePassword -- to indicate that the password should be changed after login 
alternativeContactEmail 
userStatusID -- FK to a lookup table with statuses like: active, diabled etc 
dateCreated 
dateUpdated 
lastPasswordUpdate 
lastLogon 
-- and then the rest like :forename, surname etc which are not of the interest in this question 

Ai-je raté quelque chose?

Est-ce que l'identité standard (INT) est suffisante pour userID ou est-ce que le GUID doit être utilisé à la place (l'ID utilisateur ne va pas être exposé n'importe où)?

EDIT:

• Je suis limité à l'utilisation de 1,1 .NET (ne demandez pas ...)
• L'info sel sera fusionné avec PasswordHash
• le compte serait débloqué en envoyant un mot de passe généré par un système temporaire à usage unique à l'adresse e-mail de l'utilisateur (d'où le champ onceUsePassword)

Answer 1

Pourquoi n ot juste utiliser le fournisseur d'appartenances SQL intégré si vous utilisez SQL Server de toute façon? C'est beaucoup mieux que de rouler le vôtre, car il a été testé par beaucoup de gens.

Dans tous les cas, vous devriez penser à ajouter un champ de sel à votre table.

Salting

Mise à jour: .NET 1.1? Je suppose que cela répond à ma question. Votre application est-elle destinée à la consommation du grand public? Si oui, vous pouvez ajouter un moyen pour eux de débloquer leurs comptes via une question secrète.

Answer 2

onceUsePassword - pour indiquer que le mot de passe doit être changé après connexion

Si vous devez expliquer que beaucoup, vous devez le renommer. Quelque chose comme "forceChangePasswordOnLogin".

Answer 3

Vous devez ajouter un champ « sel » d'utiliser password salting pour éviter les attaques de dictionnaire avec rainbow tables si votre base de données jamais eu compromise.

Je ne suis pas sûr de ce que vous entendez par "Les informations de sel seront fusionnées avec passwordHash". Est-ce que cela signifie que le même sel est utilisé pour tous les hashs de mot de passe? Il serait plus logique de générer un sel aléatoire pour chaque hachage, et de le stocker dans un champ séparé.