Création de mon premier webservice, en quête d'avis :)

Human Coders
#1

Salut les Human Coders !

Je viens aujourd’hui vous faire part de mon projet : Le mot de passe ayant une place importante dans notre quotidien, il est de nos jours malheureusement peu sécurisé, c’est pourquoi j’ai décidé de créer mon webservice : https://secure-password.fr

En quoi il consiste ? Tout simplement à protéger les utilisateurs de votre site internet en les empêchant d’utiliser des mots de passe courants ou déjà piratés et disponibles en clair sur internet.

Actuellement seule l’API est disponible, mais j’ai pour projet de l’adapter sur mobile afin de permettre aux utilisateurs de sécuriser leurs comptes sur le web. Je précise également que mon service est en règle avec les normes de la CNIL.

Amis développeurs, webmasters ou autres, votre feedback me serait très précieux ! 250 Requêtes vous sont offertes à l’inscription afin que vous puissiez vous faire votre avis.

Si le projet vous plait, n’hésitez pas à acheter un pack de requêtes en guise de dons car j’aurai besoin de votre soutien pour assurer le serveur pendant plusieurs années et d’optimiser le service pour le rendre plus rapide et plus complet.

Je reste à votre disponibilité pour toutes autres questions.

En remerciant vous remerciant d’avance,

Technologiquement votre, Noxyra

#2

Est ce que ton service s’inscrit dans le domaine des services d’identité sécurisée tel que Stormpath ?

#3

Salut et merci pour ta réponse !

Je ne suis pas certain d’avoir bien compris ce qu’est stormparh, néanmoins si il s’agit d’un service d’authentification délocalisé (à la manière des “singin with google/facebook”, ce n’est pas le cas ^^.

Sécure password n’est pas là pour stocker des identités (bien que, ça me trotte dans la tête ^^’), il s’agit simplement de faire une passe de vérification de sécurité sur le mot de passe de l’utilisateur lors de son inscription sur un site internet.

J’ai répondu à ta question ? :)

#4

Ok c’est un outil de "password security strenght checker"
Ca le fait penser : ça vaudrait potentiellement le coup que tu dev un web component pour Angular et React par exemple, pluggé avec l’API de ton service.
Sous forme d’une dépendance NPM.
Ca faciliterait l’adoption. Digression terminée 😁

Stocker des identités, ça t’expose a pas mal de contraintes juridiques et autres non ?
.

#5

Je pensais faire un bundle pour symfony, un plugin jQuery, et un plugin Wordpress déjà, mais je prends note pour react et angular :)

C’est possible, je me suis pas encore renseigné ^^

#6

Ça m’intéresse donc j’ai testé un peu. Voici quelques remarques si ça peut aider:

{"statusCode":201,"message":"Tout s'est d\u00e9roul\u00e9 correctement","password":{"password":"blablibloblu","date_ajout":"2017-07-16T10:34:45+02:00","secure":false,"reason":5}}
  1. Je ne mélangerai pas l’anglais et le français dans la réponse.
  2. Avant de donner des exemples d’utilisation en php/python/etc je donnerai un exemple avec curl. Juste curl en ligne de commande. Je sais pas vous, mais moi je teste toujours les nouvelles api de cette façon, et ça permet de savoir tout de suite quoi/comment faire avec n’importe quel langage…
  3. Je n’ai pas trouvé une description claire et précise des règles qui font qu’un mot de passe est bon ou mauvais. C’est pourtant le coeur de ce que tu vends, non ?
  4. La première chose qu’on va te demander d’ajouter (j’en prend le pari) c’est de pouvoir modifier les règles. En tous cas c’est ce que je voudrais voir avant d’acheter des requêtes ;)
  5. Un mot de passe peut être non sécurisé à cause de plusieurs raisons, je m’attendrai donc à recevoir plutôt "reasons":[5,4,3] dans la réponse
  6. Pour quelle(s) raison(s) as tu choisi de passer les arguments de la requête dans les headers ? Pourquoi pas en json dans le corps de la requête ? Je suis curieux ;)
#7

Je ne mélangerai pas l’anglais et le français dans la réponse.

De manière générale, je pense que je ne renverrais jamais de français dans une API; à part pour les UGC bien évidemment.

Je confirme aussi qu’il serait bien de pouvoir modifier les règles. Soit du custom en paramètre, soit une série de paramètres du style :

?L=8 (length 8)
&S=1 (special caracter needed true (1) / false (0))
&U=1 (uppercase & lowercase needed : true / false)
&C=/regex/

Aussi, je basculerais sur du “.com” pour le TLD.

Voilà voilà ! Bon courage pour la suite, j’espère que ça fonctionnera pour toi :)

#8

message i18N :
message en anglais ET/OU un Enum, que le dev peut à loisir mapper avec son propre dico

règles custom
il se passe quoi si tu crée tes propres règles ?
elle sont théoriquement susceptible de dégrader la robustesse du checker…
Quid du fournisseur de service ? comment peut-il continuer de garantir un algo de verif basé sur des critères qui ne sont plus ceux qu’il fournit en standard ?

TLD
ya pas des extensions à sémantique plus adéquate, genre “.secure” ?
c’est mieux pour le SEO le “.com” ?

#9

Bin des valeurs standards ne sont rien de plus que… des valeurs standards. Si la valeur standard est de 10 caractères minimum pour un mot de passe et que j’ai un client qui veut 12 minimum, soit je peux le faire, soit le service ne me convient pas.

Un autre exemple:

Pour mes besoins, ce qui rend ce service intéressant c’est qu’il confronte un mot de passe à un ensemble de dictionnaires. C’est son point fort. C’est même au départ l’unique chose qui m’intéresse. À elle seule cette fonction justifie que je paye pour ce service.

Mais l’auteur a choisi d’ajouter d’autres vérifications, comme la taille, l’utilisation de chiffres, etc. Ok, sauf que si je ne peux pas désactiver ça, le service en lui-même ne m’intéresse plus du tout.

#10

Bonjour à tous !

J’aurais du préciser, et je vais le préciser sur le site aussi que le projet est actuellement en bêta. Je suis tout seul a le développer et parfois je m’embrouille entre anglais et français. Je vais corriger ça rapidement, proposer l’API uniquement en anglais [ seul le plugin JS sera multi langue. ] et intégrer les locales sur le site afin de pouvoir gérer anglais et français facilement.

Je vais commencer par répondre à la question la plus simple … Je n’ai pas le .com car il est déjà pris, cependant je réfléchis à l’achat d’un .io du fait qu’il ne soit pas zoné.

Je n’ai cependant pas l’intention de proposer des règles personnalisés, peut être plus tard, mais je ne suis pas certain de ma crédibilité future si je permets a mes utilisateurs d’utiliser des mots de passe non sécurisé (et potentiellement répréhensible par la CNIL).

Personellement j’utilise plus Postman que le bon vieux cURL, mais je peux effectivement fournir des documentations pour les deux … Merci pour l’idée :)

Ce n’est pas bête cette histoire de refus pour plusieurs raisons, je vais très probablement le mettre en oeuvre !

Pourquoi j’ai choisit le header … excellente question, j’aurais aussi pu les faire passer par l’URL malhereusement beaucoup de caractères sont interdit, pour ce qui est de cette histoire du corps de requête … C’est ma première API et je n’avais pas connaissance de ce procédé. Je vais l’étudier et si je le trouve pertinent j’essayerais de proposer les deux solutions dans l’avenir.

J’espère avoir répondu à toutes vos questions, à bientot ! :)

#11

Hey, merci pour vos réponses !

Cet après midi j’ai écrit un sacré pavé, mais il a terminé en spam.

Je note quand même que l’idée de pouvoir modifier les critères supplémentaires j’aurais du y penser, c’est pas important, c’est juste capital ! J’avais beaucoup de mal a l’idée que quelqu’un puisse abaisser le niveau de sécurité, mais il me suffit simplement de fixer des valeurs minimales !

Vous aurez la suite de ma réponse si je suis retiré des spams … En tous cas merci pour vos réponses elles me sont plus qu’utile !

#12

Je pense que c’est intéressant d’avoir ce genre d’API. Je partage les avis précédents.
Cependant, en terme d’adoption, il y a un point crucial qu’un psychorigide de la sécurité va se poser :

Qu’est-ce qu’il me prouve qu’il n’est pas en train d’enregistrer mes mots de passe pour les réutiliser par la suite ?

Sur ton site :

Nous ne gardons aucune trace de vos mots de passe.

Mais où est la preuve ? On n’a pas le code source (en tout cas, je ne l’ai pas vu depuis la page d’accueil). On n’est pas en mesure de vérifier ces dires.

Sinon, comme ça avait été énoncé : Le mieux, ce serait de proposer un composant qui fait la vérification automatique, avec des messages clairs i18n pour éviter qu’on refasse un même travail sur cette partie. Par contre, il faudrait peut-être changer le mode de transaction (à la requête ? Dans ce cas, un utilisateur va générer n requêtes ? car tester n mots de passe ? Il faut tester une fois qu’il sort du champ seulement ? Pas avant ? etc.).

Honnêtement, je suis partant pour ce genre de solutions, mais ne sais pas si je pourrai aisément les vendre à mes clients.

#13

Nous ne gardins aucune trace de vos mots de passe

Prouver par la lecture du code source, ca me parait peu probant.
tu peux déposer sur Github une version qui n’est pas celle qui est en prod.
La seule vraie preuve sera juridique. Et c’est celle la qu’ira vérifier un décideur.
Mais est ce que juridiquement il existe un moyen d’attester, prouver ce qui relève du déclaratif ?
Sur quoi s’appuient d’autres éditeurs de services similaires ?
un texte, un label, une charte légale, …?

Transaction
Effectivement ca devient couteux en nombre de requêtes. Faut demander a un ingé de chez Google Map
comment ca se passe chez eux :D.
C’est le dilemme :

  • soit faire la verif coté serveur mais c’est couteux en round-trips.
  • Soit le faire côté client en JS (et autres si mobile natif, …). A part la gestion du caching de version, ca me parait vertueux.
  • soit l’un et/ou l’autre via un framework isomorphique (si c’est bien ca que fait l’isomorphisme)

I18N
le problème avec les message traduits préformatés c’est que ya de grandes chances que ton client veuille customizer le message.
La comme ca je dirais qu’il ya 2 facons de faire :

  • soit le service renvoie une Enum, et charge au dev de faire un mapping avec la liste des phrases rédigées par le client
  • soit tu donnes accès au un back office rattaché à ton web service, où chaque client peut librement rédiger ses propres message en face de chaque élément d’Enum. Et pour chaque requête tu passe le token qui va bien.
#14

Hey !

Pour l’internationalisation, je suis entrain d’y travailler. J’ai récolté pas mal d’avis et je me suis fait une idée de ce que je peux faire pour améliorer cette partie.

Concernant la sécurité … Je me permet de vous coller la réponse que j’ai déjà donné à un utilisateur de linkedin curieux :

Citation : … Concernant la sécurité, déjà tu passes obligatoirement par le HTTPS donc ton mot de passe ne circule pas en clair sur le réseau (Ce qui n’est pas encore le cas de tous les sites d’ailleurs …) et donc les risques sont au final les mêmes que sur tous les autres accessible en HTTPS, minime. Qu’es ce qui prouve que je les garde pas ? Toutes mes informations personnelles sont dans les mentions légales … J’ai envie de créer une entreprise, non pas de partir en taule.

#15

Ce que j’avais indiqué, c’était en terme d’adoption. Beaucoup ne vont même pas se poser la question et vont tout de suite refuser. Ce qu’il faut, c’est te préparer un discours, une FAQ et d’autres supports pour appuyer ta vision des choses.
Dans tout ce qui est sécurité, il y a souvent des « extrémistes » qui ont pas mal d’influence (il faut passer les barrières des développeurs, des décideurs, des audits de sécurité, des clients et surement d’autres tiers). Je ne sais pas comment le tourner, mais n’hésite pas à t’intéresser au sujet, en discuter avec d’autres, pour voir comment tourner cette notion à ton avantage.

1 « J'aime »
Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s