2010-03-25 6 views
3

En utilisant MySQL et PHPPassword Validation

Y at-il raison/valeur lors de la vérification d'un mot de passe pour interroger la base de données en utilisant le nom d'utilisateur et mot de passe (après désinfection, bien sûr) et l'enregistrement d'une tentative avortée quand aucune ligne sont renvoyés vs interroger la base de données en utilisant le nom d'utilisateur, puis en comparant la chaîne de mot de passe de retour?

EDIT: Pour ceux qui l'ont mentionné ci-dessous, oui le mot de passe est hashé dans la base de données.

+0

+1 On dirait une question de méthodologie parfaitement valable pour moi. Je ne comprends pas la downview – Dathan

+1

Parce que certaines personnes sont stupides? – animuson

Répondre

1

Je vois 2 questions ici.

  1. La manière générale de vérifier les informations par rapport à la base de données est de créer une base de données. Donc, mettez le login et le mot de passe dans la requête. Surtout si nous stockons un hachage, pas un mot de passe lui-même
  2. La protection de deviner le mot de passe est un ajout précieux à tout système d'autorisation.
+0

Est-ce que la base de données compare mieux que PHP? – Young

+0

@SpawnCxy oui, en général. Peu importe dans ce cas particulier. –

+1

Je ne dirais pas ça. Franchement, selon la façon dont le mot de passe est stocké, vous pouvez obtenir des résultats bizarres lors de la comparaison en MySQL et avec PHP. Parce que les chaînes sont souvent stockées avec un classement non-binaire, cela permet, par exemple, une comparaison "lâche" comme "A" = "a" 'ou même' "ß" = "ss" '. Mais si vous stockez uniquement les hashs des mots de passe dans un jeu de caractères distinct (comme hexadécimal), tout va bien. – Gumbo

4

Si je vous comprends bien, vous vous demandez s'il y a une différence entre la comparaison des résultats de:

$results = mysql_query("SELECT name FROM users WHERE name = $properlyEscapedName AND pass = $properlyEscapedPassword"); 
if (mysql_num_rows($result) == 1) 
    $authenticated = true; 

contre

$results = mysql_query("SELECT name, pass FROM users WHERE name = $properlyEscapedName"); 
$array = mysql_fetch_assoc($results); 
if ($array["pass"] == $unescapedPass) 
    $authenticated = true; 

Je note qu'il est préférable de stocker les mots de passe que les mots de passe en clair pour des raisons de sécurité, mais sinon la seule différence que je vois est que dans le premier cas, vous retournerez un champ de moins, ce qui peut signifier une utilisation plus efficace de la bande passante. D'un autre côté, votre requête est plus grande de plusieurs octets, ce qui atténue probablement le petit avantage du jeu de résultats plus petit.

+0

Oui, vous comprenez correctement. – Humpton

+1

OMG, "bénéfice du jeu de résultats plus petit" –

0

Il n'y a fondamentalement aucune différence entre les deux méthodes. Les deux méthodes vous permettront de savoir si le mot de passe ne correspond pas au nom.

0

Plus vous faites de travail/plus vous maintenez une connexion ouverte après une tentative de connexion échouée, plus vous vous laissez ouvert à une attaque DOS. OTOH vous devez équilibrer cela contre la prévention des recherches de force brute. Une solution plus intelligente consiste à repousser le nombre de tentatives d'échec côté client dans un cookie chiffré (déposer le cookie avant que l'utilisateur ne se connecte à la page de connexion - s'il tente de publier un nom d'utilisateur et un mot de passe sans cookie). - avec un message que les cookies doivent être activés). Incrémenter les échecs et re-chiffrer pour supprimer un nouveau cookie si la connexion échoue, après 3 échecs consécutifs échouent toute tentative.

Cela n'empêche pas complètement les attaques par force brute, mais les rend beaucoup plus difficiles.

C.

1

Vous avez un compromis entre l'information donnée à l'utilisateur et à la protection contre les attaques.

Si vous interrogez votre base de données en recherchant le nom d'utilisateur et le mot de passe correspondants et que cela échoue, vous pouvez seulement dire à l'utilisateur que le nom d'utilisateur ou le mot de passe est erroné. Ne pas aider s'il ne se souvient pas du login que vous avez utilisé pour vous enregistrer (était-ce "Arkh01", "arkh" ou "Arkh1").

Si vous interrogez votre base de données pour la connexion, obtenir le hachage et le sel, vous pouvez dire à l'utilisateur si la connexion est erronée ou le mot de passe. L'utilisateur est content. Mais quelqu'un attaquant votre site Web peut facilement apprendre que l'utilisateur "aa" n'existe pas, mais que l'utilisateur "ab" le fait.Comme beaucoup de sites Web donnent accès à une liste d'utilisateurs, vous pouvez presque toujours ignorer cette préoccupation.

Pour éviter la force brute, consignez le nombre de tentatives effectuées par une adresse IP ou une connexion et bloquez toute tentative ultérieure après des erreurs 5ish. De préférence bloquer l'adresse IP utilisée, pas le compte.

sur le stockage des mots de passe hachés, utiliser des sels et HMAC + sha512 en php: hash_hmac