Version imprimable
Bonjour,
Avez vous un plan pour crypter le mots de passe avec JS avant de les passer au BAck End pour qu'il enregistre le mot de passe?
Quel type de champs mysql dois-je alors créer pour le stocker ?
Comment ensuite décrypter dans le front end ?
Merci !
Salut,
Source : https://stackoverflow.com/questions/...sence-of-httpsCitation:
There is no way to send a password securely that the user can verify without SSL.
Sure, you can write some JavaScript that will make a password secure for over-the-wire transmission through hashing or public-key-encryption. But how can the user be sure that the JavaScript itself has not been tampered with by a man-in-the-middle before it reached them, to send the password to an attacker instead of the site, or even just compromise the security of the algorithm? The only way would be for them to be expert programmers and have them inspect every line of your page and script to ensure it was kosher before typing the password. That is not a realistic scenario.
If you want passwords to be safe from man-in-the-middle attacks, you must buy an SSL cert. There is no other way. Get used to it.
If I use MD5, one can reverse that password string.
No... not trivially at least. Whilst MD5 has attacks against it, it's a hashing algorithm and thus unreversable. You would have to brute-force it.
But again, a man-in-the-middle attacker doesn't need to look at your MD5s. He can simply sabotage the JavaScript you send the user to make the MD5s.
SSL cert => https://letsencrypt.org/
Sinon pour sécuriser les échanges de données JWT et JWE:
JSON Web Tokens
https://auth0.com/docs/jwt
How do JSON Web Tokens work?
Pièce jointe 297447
JWE
Source : https://security.stackexchange.com/q...claims-payloadCitation:
Do NOT encrypt your own JWT!! There is an actual specification that defines how to encrypt JWTs (called JWE): https://www.rfc-editor.org/rfc/rfc7516.txt
JWE uses authenticated encryption which means that the plaintext is first encrypted and then an integrity check is produced over the ciphertext. You can get more info on what the plaintext looks like from Section 5.1 of above Spec.
It is possible to securely store access policies in the payload of your JWT if you use either encrypted or signed formats. You may want to use encrypted if you don't want the client or other parties to have any knowledge of the policy data. If you don't care who can read it and you only care about who can change the values, use signatures only.
Remember though that the more security you add, the bigger the performance impact so use your judgement on what is needed.
Final note: Key management of the signature and encryptions keys also becomes an important issue for you to consider, because at the end of the day, whoever has access to the keys can decrypt your JWE or modify the signature of your JWS. So make sure you use good safety practices in where you store the actual keys, who has access to them and how they are used and kept in memory.
Merci, Ca m'a l'air balaise.
et j'avais entendu parler de cryptage md5 dans les champs de bdd puis décryptage dans le font end ou le back end ?
Salut,
La méthode de cryptage md5 est suffisante en règle générale. Mais tout dépend de ce que tu veux faire exactement.
Je ne vois pas trop l'intérêt de crypter côté client (front end) mais peut-être as-tu une explication.
Le type de champs à utiliser en BdD est du varchar (32).
Salut,
Ont parlent de hashage pas de cryptage .
https://blog.developpez.com/sqlpro/p...dans-les-sgbdr
Le Md5 c'est un peu juste ,tu peux télécharger une rainbow table et ou voir le nombre de site proposant ce service .
https://fr.wikipedia.org/wiki/Rainbow_tableCitation:
La table, qui ne dépend que de la fonction de hachage considérée, est constituée d'une grande quantité de paires de mots de passe. Pour obtenir chacune de ces paires, on part d'un mot de passe, et on calcule son empreinte. Une « fonction de réduction » qui varie selon la position dans la table permet de recréer un nouveau mot de passe à partir de cette empreinte. On itère ce processus, et après un nombre fixe d'itérations, on obtient un mot de passe qui forme le deuxième élément de la paire. La table, créée une fois pour toutes, permet la recherche d'un mot de passe, connaissant son empreinte par la fonction de hachage considérée.
je partirai plutôt vers du Sha et obliger le customer à adopter un mot de passe fort ,minuscule, majuscule, caractère spéciaux et chiffres et surtout être en https.
Mais si tu es en https, que tu utilise jwt et un mot de passe fort hashé en sha-512 , la tes bien :mouarf:.
Je maintiens, md5 me semble suffisant pour sécuriser le profil d'un utilisateur. Mais ça ne concerne que moi.
D'autant plus qu'on n'est pas obligé de ne crypter que le mot de passe, on peut y associer un id et d'autres informations relatives à l'utilisateur (perso c'est ce que je fais), autant dire qu'une rainbow table ne pourra rien y faire. Si en plus, on oblige l'utilisateur à saisir un mot de passe fort, c'est quasiment du délire de pirater un compte.
Là encore, tout dépend de ce qu'on veut sécuriser.
Merci beaucoup, c'est super sympa.
Oui en effet j'avais vu qu'on pouvait ,sauf erreur, crypter en MD5 dans le front end , avec js puis l'envoyer au back end en ajax crypté. Mais en effet, à ce moment là, pourquoi ne pas le faire avec PHP ou Java dans le back...
Ah mais oui c'est qu'en cas de sniffing, c'est mieux de crypter dans le front end, non ? Avant que le mot de passe ne parvienne au back end, sinon le man-in-the-middle peut sniffer la requête AJAX avec le mot de passe en clair ?
C'est bien ça oui et effectivement le md5 est suffisant ,mais bon ,rien de bien compliqué à passer à la difficulté supérieur .
Effectivement c' est une question de point de vue et du niveau de sécurité dont tu estime avoir besoin .
Il y a une raison pour ne pas être en https ?
hého, vous développez quoi les mecs ?
- Du traitement de données pour des informations médicales sensibles;
- Une appli compta pour des narco-trafiquants;
- L'administration d'une centrale nucléaire sous cage de Faradet;
- Un Vlog pour les vidéos de vacances;
- ...
La plupart des tentatives de hack sur le web est l'injection sql. Si tu te préserves de ce côté là, tu ne risques rien. Et puis, si on pirate ta collection de vidéos, qu'est ce que tu en as à faire.
Passe du temps à faire du SEO, de l'UX-UI, la sécurité, tu verras ça plus tard si besoin.
MD5 est suffisant, je le répète.
Md5 est suffisant "pour le moment" mais concidéré comme obsolète .
La techno supérieur est facilement réalisable et encore je parle pas de sha-512.
Sécurisé à 99% n'est pas 100% , il pourrait très bien faire un site de rencontre où vouloir simplement bien faire au lieu de juste "suffisant" à un instant T.
Combien ce sont fait avoir avec ce genre de raisonnement ne prévoyant pas que l'informatique va très vite et qu'il y à toujours plus malin que soit .
OK, qui peut le plus peut le moins. Mais les fantasmes de piratage sont légions et plutôt rares aux vues de toutes les tentatives.Citation:
Envoyé par Biomega
Je suis bien d'accord avec toi , à l'heure actuelle ça reste en grande partie du fantasmes .
