À l'aide de jBCrypt de sel des mots de passe dans l'Application Android provoque un long accrocher

Je suis en utilisant le jBCrypt Bibliothèque de hachage des mots de passe des utilisateurs lors de leur inscription à l'aide de mon application.

Je suis l'aide de la base en fonction de hachage, avec un sel d', comme suit:

String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt());

J'ai remarqué un une à deux minutes à accrocher lors de l'inscription, et vérifié le débogueur, confirmant BCrypt était responsable.

Ne saler le mot de passe de prendre vraiment que beaucoup de puissance de traitement? Si oui, serait une bonne alternative à envoyer le mot de passe en clair pour le serveur de hachage? Ma pensée originale sur la question était de hachage avant qu'il ai envoyé n'importe où. Des idées?

Eh bien, en un sens, bcrypt est conçu pour faire exactement cela. Bien sûr, si elle provoque une longue accrocher le client, il n'est pas acceptable.
Vous avez essayé d'exécuter le processus de hachage sur un autre thread en plus de l'INTERFACE utilisateur? (par exemple: android.os.AsyncTask)

OriginalL'auteur WilHall | 2011-10-02

  1. 11

    Ici est un article qui indique le nombre de fois prises sur un ordinateur portable Mac avec un processeur Core 2 Duo. Donc, oui, Bcrypt est susceptible d'être très lent sur un appareil mobile.

    Un autre problème commun est l'initialisation de SecureRandom qui peut être très lent et peut également se bloquer en raison de l'absence de suffisamment de données aléatoires. Cela peut varier entre les différentes machines et systèmes d'exploitation. Vous trouverez beaucoup de discussion de cet ailleurs, mais c'est quelque chose que vous pouvez tester soit l'initialisation de vous-même en utilisant new SecureRandom() ou en appelant gensalt séparément pour isoler l'aléatoire de la génération de données et puis vient l'heure de l'appel à hashpw.

    Une autre question est de savoir pourquoi vous voulez réellement de hachage sur le client? Si vous êtes à la stocker sur le client et connecté localement, alors que peut faire un certain sens, mais si il est envoyé à un serveur et une connexion normale implique l'envoi d'un mot de passe en clair sur le serveur alors vous n'avez pas gagner quoi que ce soit. Aussi, une idée fausse commune est que le hachage d'un mot de passe avant de l'envoyer au serveur (lors de la connexion) offre une certaine protection, alors qu'en fait, il est équivalent à l'envoi du mot de passe en clair. Un attaquant a seulement obtenir la valeur de hachage pour être en mesure d'accéder.

    Hachage des mots de passe est un moyen d'empêcher un attaquant d'accéder (ou au moins les ralentir) si le mot de passe du magasin lui-même être compromise.

    Donc si le mot de passe est stocké sur le serveur, il doit être envoyé en texte clair (sur un canal sécurisé) et le serveur doit prendre la décision sur comment il est haché.

    La différence entre l'envoi d'un hachage d'un mot de passe à partir du client vers le serveur et d'envoyer le mot de passe en clair, c'est que si il est intercepté, il est uniquement valable pour le domaine. Inter-domaine des compromis (par des personnes de réutiliser le même mot de passe sur plusieurs sites) sont assez communs.
    BCrypt utilise un hasard sel si, dans la pratique, on ne pouvait pas vérifier le mot de passe sauf s'il a été stocké en clair sur le serveur ou vous avez envoyé le sel au client avant il a calculé la valeur de hachage. Si vous utilisez un canal sécurisé comme HTTPS (que vous devriez toujours), alors vous ne pouvez pas gagner beaucoup en termes de protection contre l'interception en transit. Partagé les mots de passe des compromis sont généralement à la suite du mot de passe de la base de données de vol et d'être en texte brut ou haché à l'aide d'un mauvais choix de l'algorithme.

    OriginalL'auteur Shaun the Sheep