2010-07-19 6 views
0

J'ai développé une bibliothèque de connexion pour un site web en utilisant CodeIgniter. Le code d'authentification est le suivant:Salage en PHP et MySQL

function signin($username, $password) 
{ 
    $CI =& get_instance(); 
    $query_auth=$this->db->query('SELECT user_id, banned FROM user WHERE username=? AND password=SHA1(CONCAT(?,salt)) LIMIT 1', array($username, $password)); 

    if($query_auth->num_rows()!=1) 
     return 2; 
    else 
    { 
     if($query_init->row()->banned==1) 
      return 3; 
     else 
     { 
      $CI->load->library('session'); 
      $this->session->set_userdata('gauid', $query_auth->row()->user_id); 
      return 1; 
     } 
    } 
} 

Les valeurs de retour indiquant la réussite, l'échec ou l'interdiction. Chaque utilisateur a un sel unique stocké dans la base de données.

À l'origine j'ai attrapé le sel de la base de données, combiné le mot de passe entré d'utilisateur et le sel de la base de données dans PHP, puis interrogé la base de données encore avec la valeur combinée. Je pensais que cela accélérerait les choses car un seul voyage dans la base de données est requis et il y a moins de code. Je pensais aussi que ce serait tout aussi sûr, mais après avoir lu le top Reponse à cette question Salting my hashes with PHP and MySQL ...

Tout d'abord, votre SGBD (MySQL) ne pas besoin d'avoir un soutien pour cryptographique hashes. Vous pouvez faire tout cela sur le côté PHP, et c'est aussi ce que vous devriez faire.

... J'ai commencé à me demander s'il y avait un problème de sécurité que j'avais négligé de repérer.

Y at-il réellement quelque chose qui ne va pas dans ce code?

+0

duplication possible de [Secure hash et salt pour les mots de passe PHP] (http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) – rook

+0

Je ne vois pas comment c'est vrai! Les questions sont complètement différentes. – j82374823749

+0

Ensuite, il devrait être fermé pour être trop localisé. – rook

Répondre

2

Rien de faux en soi. Gardez à l'esprit que tout trafic véhiculant le mot de passe non crypté/non sécurisé est suspect. Ainsi, par exemple, lorsque le serveur est distant et qu'il ne fonctionne pas avec le cryptage lors de la communication avec ce serveur, il est encore temps de tenter d'intercepter un mot de passe. En outre, si les requêtes sont enregistrées quelque part (soit par défaut, soit parce qu'elles sont lentes), vous avez un mot de passe simple + le sel que vous utilisez assis dans ces journaux, après tous les problèmes que vous avez rencontrés. quelque part. Si vous l'avez fait en privé dans votre propre code, cela ne se produirait pas.

Tout dépend de la façon dont vous aimez être paranoïaque. Il est beaucoup plus facile d'abuser et souvent des maux oubliés, comme la fixation de session.

+0

Désolé, animal de compagnie sur soi-même. :) –

+0

Tant que vous réfléchissez à des problèmes de sécurité comme celui-ci, je n'appellerais pas la journalisation de toutes les tentatives de mot de passe en clair comme une chose mineure. Autrement convenu comme ci-dessus. –

+0

hashing! = Cryptage – rook