Discussion :

[vertebre]

Je me retrouve face à un problème de compréhension vis à vis de la gestion et de la vérification du mot de passe entrée par l'utilisateur pour se logger depuis des champs d'identification (login, password).
J'aimerai savoir aussi "quand il apparait en clair ou non"

J'ai bien conscience que je ne dois pas stocker ou utiliser le mot de passe de l'utilisateur en clair dans une application, je devrais plutôt appliquer un hash dessus ou une fonction de chiffrement.
Mai c'est là que j'ai une zone noire.

Lorsque l'utilisateur entre son mot de passe et que la fonction de hash ou de chiffrement va y être appliqué, le mot de passe se retrouve bien en clair quelque part dans la mémoire ?
D'autre part, lors de l'implémentation de cette fonction de hash ou de chiffrement ...
-si je l'implémente coté client alors ma fonction est potentiellement connue par l'utilisateur ?
-si je l'implémente coté serveur alors comment transmettre le mot de passe de façon sécurisé ?

Quel est la meilleur implémentation, coté client ou coté serveur ou les deux ?

---

Enfin, concernant les fonction de hash disponible pour PHP:

J'ai trouvé ceux ci qui ne sont pas fiables :
- md5
- sha512
- tiger192
- ripemd320
- adler32
- crc32b
- fnv132
- joaat
- haval256

J'ai trouvé ceux ci qui serait fiable, notamment whirlpool et Bcrypt mais qui ne serait pas adapté sur du matériel avec mémoires et performances restreintes
- Bcrypt
- gost
- snefru256
- whirlpool

Laquelle serait le meilleur compromis entre performance et sécurité pour une application mobile ou en existe il d'autres ?

Est il envisageable d'utiliser un VPN pour transmettre ces informations plutôt que d'utiliser un hash ou bien vont ils de paire ?


Merci de m'avoir lu, dans l'attente de lire vos réponses ...

Bonne journée,

[Loceka]

D'autre part, lors de l'implémentation de cette fonction de hash ou de chiffrement ...
-si je l'implémente coté client alors ma fonction est potentiellement connue par l'utilisateur ?
-si je l'implémente coté serveur alors comment transmettre le mot de passe de façon sécurisé ?

Si tu peux l'implémenter côté client c'est préférable bien entendu. Quoi qu'il en soit il faut utiliser une fonction de hashage avec un salt. Le seul souci de le faire côté client est que le salt peut du coup être connu d'un attaquant (à moins de demander le salt au serveur).

Si tu dois l'implémenter côté serveur (cas typique d'une page web), il faut du coup chiffrer la connexion dès le départ (https/SSL), le mot de passe ne transite donc pas en clair sur le réseau.

Après, bien entendu, il est forcément "en clair" à un moment donné en RAM sur le client, même s'il existe des moyens de chiffrer la RAM et de la nettoyer après (moyens que je ne connais absolument pas personnellement).

Concernant les fonctions de hashage, je dirais que le SHA512 reste un bon compromis à l'heure actuelle, surtout avec un salt. Mais si tu en trouves une plus sécurisée, fonce.

Par contre oublie le chiffrement pour le mot de passe. Un chiffrement implique qu'il existe une fonction inverse permettant de déchiffrer, ce qui ajoute un risque inutile par rapport au hashage du mot de passe.

[spawntux]

Bonjour,

Je rejoins le post du dessus mais me permets de poser une vision "sécurité". La question de base c est "de qui et de quoi souhaites tu te protéger ?"

Le HTTPS est une réponse à une menace d interception sur le réseau, il y eu réflexion sur le hash côté client qui de mon point de vue n apporté que peu d intéret.

Je m explique le hash de mot de passe est une "protection" contre une menace de type compromission de la database ( via SQL injection par exemple) le fait d envoyer le hash déjà effectué côté client ( en partant du postulat http) ne protège en rien et en cas de salt côté client pourrait te mener a un cassage massif de tout les hash de ta dB (j exagère un peu mais c est l idée).

De ce fait ma solution c est HTTPS pour se protéger de la menace Mitm et hash sha512+salt (côté serveur) qui protégera le compte en cas de compromission de ton authentification. Ca permet une simplicité de dev, certe une conf bien carré de HTTPS doit être faite mais bon :p

À+

[Loceka]

le fait d envoyer le hash déjà effectué côté client ( en partant du postulat http) ne protège en rien

Oui, c'est vrai si on considère uniquement l'application/site à protéger.
Mais si on considère le problème d'une vision plus large, en s'intéressant à la protection du mot de passe de l'utilisateur et non de l'accès à l'application/site, le hash du mot de passe permet de ne pas exposer le mdp en clair.
Je sais que c'est purement théorique parce que ça n'arrive jamais, surtout pas à moi (), mais considérons le cas où un utilisateur utilise le même mot de passe sur plusieurs sites, ou bien s'il change régulièrement de mot de passe en l'incrémentant, le fait de hasher côté client et de ne pas exposer le mdp en clair permet d'empêcher l'attaquant d'accéder à une information qui pourrait lui être utile plus tard.

Ca ne résoud certes pas tout mais c'est une sécurité supplémentaire. Mais il est vrai que dans ce cas il faut faire attention au salt, soit le demander au serveur, soit utiliser autre solution mais ne pas avoir le salt en dur côté client.

[vertebre]

@Loceka

je dirais que le SHA512 reste un bon compromis à l'heure actuelle, surtout avec un salt. Mais si tu en trouves une plus sécurisée, fonce

euh oui justement dans mon 1er post j'en ai trouvé des plus sécurisées, mais apparement plus lourdes. Comme je n'ai pas expérimenté l'impact sur les performances d'un appareil à ressources restreintes(smartphone, tablette, etc...), quelqu'un aurait il des retours là dessus svp ?

@spawntux

Bonjour,

c est de qui et de quoi souhaites tu te protéger

Je veux que mon application soit protégée par :
-le mitm
-les injections SQL
-le reversing, analyse de l'application et précisément de la RAM

@all
merci, vos explications sont d'une grande aide pour moi.
Je compte retenir la mise en place d'une connexion https et la mise en place du hash+salt coté serveur.

Mais il y a encore une petite zone d'ombre, c'est au niveau de la mise en place du hash+salt coté serveur avec transmission en https ... mais du coup soit:
-je transmet le mot de passe en clair du client au serveur, certes dans un tunnel ssl.
-ou j'envoie le mot de passe hashé au serveur mais du coup je ne met plus en place le hash+salt coté serveur et un attaquant pourrait avoir une indication grâce au mdp hashé.
-ou j'ai zappé qqch ?


Ce que je souhaiterai c'est pouvoir transmettre au serveur le mot de passe(pas en clair), mais sans implémenté le hash+salt coté client.
Si je saisie ce que tu dis Loceka, c'est que je dois appliqué le hash de mon mot de passe coté client, l'envoyer au serveur et y appliquer le salt ??


bonne soirée à vous,

[Loceka]

Si je saisie ce que tu dis Loceka, c'est que je dois appliqué le hash de mon mot de passe coté client, l'envoyer au serveur et y appliquer le salt ??

Non, ce que je dis c'est que tu dois demander le salt au serveur (salt connu uniquement par le serveur et lié au login) et crypter le mdp côté client avec hash + salt.

Par contre est-ce qu'il s'agit d'une page web ou d'une application (hors navigateur donc) communiquant avec un serveur ?

S'il s'agit d'une page web, certes javascript permet de chiffrer/crypter mais ça reste moins sécurisé que ce que tu peux faire depuis une application "lourde" étant donné que tu as moins de contrôle sur la RAM, que tu peux plus facilement être exposé à du mitm actif ou à du XSS.

S'il s'agit d'une application lourde, tu peux d'ailleurs te passer de HTTPS (et de HTTP tout court) et passer par un protocole PGP qui est plus sécurisé.
Là encore c'est aussi faisable en Javascript - avec les mêmes réserves que précédemment - mais ça nécessite une machine suffisament puissante pour générer des clefs RSA (bon, dans le cas d'une application lourde aussi mais je pense que le JS nécessitera plus de ressources, à confirmer).

En gros y'a plusieurs facteurs à voir et il faudra adapter le niveau de sécurité en fonction :
- est-ce une page web ou une application lourde ? => Javascript + HTTPS (+/- PGP) dans le premier cas, probablement pas de contrôle de la RAM ; ton langage de prédilection + PGP dans le second
- est-ce utilisé sur un PC ou sur un dispositif mobile ? => voir l'impact sur les perfs en fonction des solutions choisies

[regma]

Non, ce que je dis c'est que tu dois demander le salt au serveur (salt connu uniquement par le serveur et lié au login) et crypter le mdp côté client avec hash + salt.

ok mais du coup je devrais obligatoirement utilisé https pour éviter qu'un attaquant s'authentifie en récupérant le mdp hashé+salt ?

Par contre est-ce qu'il s'agit d'une page web ou d'une application (hors navigateur donc) communiquant avec un serveur ?

Il s'agit d'une application smartphone.

- est-ce utilisé sur un PC ou sur un dispositif mobile ?

C'est sur un dispositif mobile

=> voir l'impact sur les perfs en fonction des solutions choisies

oui j'aurai aimé avoir des retours d'expérience de type "solutions choisies/performances" afin de prendre une décision sur quoi implémenter.

[Loceka]

ok mais du coup je devrais obligatoirement utilisé https pour éviter qu'un attaquant s'authentifie en récupérant le mdp hashé+salt ?

Non, t'es obligé de rien, mais si tu veux ajouter de la sécurité, c'est le minimum (pour le coup plutôt une solution basée sur PGP vu que c'est pas une page web).

[regma]

Non, t'es obligé de rien, mais si tu veux ajouter de la sécurité, c'est le minimum (pour le coup plutôt une solution basée sur PGP vu que c'est pas une page web).

je ne comprend pas pourquoi tu me dis que c'est une page web ?


PS: nous sommes 3 sur le problème, voilà pourquoi je me permet de répondre à la place de vertebre.

[Loceka]

je ne comprend pas pourquoi tu me dis que c'est une page web ?

Je dis que c'est pas une page web

[vertebre]

oups oui effectivement

[vertebre]

J'ai rassemblé des informations pour utiliser pgp sous android : openkeychain et son projet sous android studio mais çà me parait vraiment très flou pour moi.

D'autant plus que je rencontre des problèmes pour tester lorsque je compile le projet :

Project :libkeychain declares a dependency from configuration 'compile' to configuration 'default' which is not declared in the descriptor for project :openpgp-api-lib.

Du coup, je pense revenir sur une solution plus conventionnelle : application de la fonction hash+salt demandé au serveur, et envoie du tout en https.

Je résume ce que je dois faire ci après, peux tu me dire si les étapes sont correctes stp ?

-| Pour le serveur

• mise en place du https sur mon serveur web
• web service_RequestSalt.php pour envoyer le salt au client
• web service_TreatMdp.php pour le verifier ou l'enregistrer s'il s'agit d'un nouvel utilisateur.

-| Pour le client

• on récupère le mdp entré par l'utilisateur depuis l'editText
• tache asynchrone pour demander le salt serveur
• tache asynchrone pour appliquer la fonction de hash+salt sur le mdp
• tache asynchrone pour envoyer le mdp au serveur en https, et récupérer un valeur accès autorisé ou non.

merci encore pour ton aide,

bonne journée

[regma]

J'aurai besoin d'une confirmation ou pas pour continuer mon développement, je me permet de relancer ma question.