Follow

les dévelopeurs va falloir qu'on parle :

NON limiter en longueur un mot de passe n'est pas une bonne idée

NON interdire le copier coller n'est pas une bonne idée

Il n'est pas normal que je doive sortir du javascript comme le bout de truc ci-dessous pour utiliser ton service. Alors maintenant sortez-vous les doigts du cul et faites votre job

document.getElementById('confirmationPassword').value = 'monmdp'

@capslock D'autant plus qu'on ne stocke jamais le mot de passe en clair, on stocke un condensat donc il n'y a vraiment aucune raison SGBD de limiter la longueur.

@bortzmeyer @capslock ça on ne sait jamais comment il est stocké côté serveur 😋

@Siegi @bortzmeyer @CapsLock Le mois dernier j'ai envoyé deux mails à des sites parce que je les ai pris en flagrant délie de stockage en clair. Facile à voir, j'ai reçus mon mdp 'oublié' en clair par mail.

@Siegi quand ya une limite de caractère haute on peut présumer raisonnablement que c'est stocké en clair @bortzmeyer

@bortzmeyer @CapsLock Pas toujours. Dans EPP on est bien obligé de stocker le mot de passe (le authInfo) en clair (ou chiffré de manière réversible) si on veut pouvoir le renvoyer lors d'une commande domain:info. On peut cependant légitimement penser que ce modèle est erroné et certains registres en dévient déjà (ne retournent jamais le mot de passe mais mettent [redacted] ou similaire; ca ne dit rien sur comment il est stocké par contre)

@bortzmeyer @CapsLock Sauf qu'une tonne de services "legacy" (genre les banques) sont "architecturés" autour de vieilles solutions/briques (et pas à la place) et donc 1) de vieux SGBDR où chaque champ doit être typé en longueur et 2) de vieilles pratiques qui prédatent les techniques de dérivation de mot de passe (PBKDF >> juste condensat BTW) et les bonnes pratiques. Ce n'est pas pour rien que "eTLS" a éte poussé: certains veulent pouvoir TOUT déchiffrer sous couvert de raisons légales

@CapsLock
On fait surtout ce qu'on nous demande malheureusement même si c'est débile ....

@CapsLock
Peut être que c'est pas les développeurs qui ont le dernier mot, aussi. C'est pas eux qui détiennent le produit en général.

@Grandasse et bien dans ce cas ielles peuvent partir, ya du job ailleurs

@MarcFramboisier @Grandasse @CapsLock Surtout qu'avec le RGPD, qui rend le dev responsable au même titre que le client, et qui est une obligation de moyens, en gros, si tu ne suis pas l'état de l'art en termes de sécurité, tu te fais allumer (et c'est normal). L'arme du RGPD, ça marche super bien, depuis que je l'utilise pas un client ne m'a imposé le stockage du mot de passe ou l'envoi d'un mot de passe temporaire en clair dans un email...

@Grandasse @MarcFramboisier @CapsLock Mes salariés :) Les autres, honnêtement je ne sais pas trop, mais leurs employeurs feraient mieux ; en dehors de la conscience professionnelle, le jour où ils ont une brèche de données, si ils n'ont pas mis en oeuvre les moyens à l'état de l'art, ça pourrait mal finir. Surtout si leur donneur d'ordre est une grosse boite qui peut se payer de bons avocats.

@CapsLock Dommage, mais je comprends, avec un mot de passe très long (généré à par un gestionnaire de MDP par exemple), le retaper à la main est un peu lourd.

@bortzmeyer @CapsLock On travaille aussi sur la limite du authInfo ?

@kmk @bortzmeyer @CapsLock Quelle limite du authinfo? C'est un "normalizedString" sans limite de taille. Mais en pratique ca devient de plus en plus inutile: certains registres ne le montent même plus dans la réponse d'un domain:info (il peut être stocké haché et donc non réversible), d'autres ne permettent plus à un registrar tiers de le vérifier, d'autre ne permette pas de le choisir ou le change automatiquement après un transfert. Ce modèle n'est plus adapté...

@pmevzek @bortzmeyer @CapsLock Ah oui. Je ne sais pas pourquoi j'avais en tête une limite à 32 caractères. Mais je me trompais.

@kmk @bortzmeyer @CapsLock Tous les registres mettent une limite. Politique locale vs spécification technique

@bortzmeyer @kmk @CapsLock Discuter de la taille sans discuter du contenu me semble illusoire. Un mot de passe de 10 chiffres n'est pas plus "fort" qu'un mot de passe de 6 caractères parmi toutes les lettres de l'alphabet anglosaxon minuscules et majuscules

@pmevzek @kmk @capslock Personne n'a dit le contraire. Mais pourquoi limiter la longueur ?

@bortzmeyer @kmk @CapsLock Je ne sais pas. J'ai vérifié la 1ère mouture du draft qui a donné le premier RFC sur EPP,et la limite était déjà là (et il y avait même une regex pour limiter le choix des caractères) et pourtant cela referençait un autre document sur SASL lequel définissait un mot de passe comme étant une suite de un caractère ou plus en UTF-8. J'ai remarqué pourtant qu'on fait du XML mais qu'on cherche à limiter/raccourcir partout (comme le nom des noeuds) ce qui m'a toujours énervé.

@bortzmeyer @kmk @CapsLock Si elle part d'une bonne intention (?) malheureusement cette extension mélange des choses sans rapport, et fait des mauvais choix aussi (comme la chaîne fixe "[LOGIN-SECURITY]"). Le vrai sujet aurait été d'étendre proprement le modèle de sécurité d'EPP et se standardiser sur SASL par example mais personne ne semble vouloir travailler à ce sujet et l'auteur du draft semble ne pas connaître/rejette l'idée. Je ne prédis pas un grand avenir à cette extension.

@CapsLock protip: $0 est une variable magique qui contient le dernier élément sélectionné dans l'inspecteur. On est donc plutôt sur un

$0.value = 'foo';

Aussi n'oublions pas les pires raclures de l'humanité que sont les banques et le gouvernement qui demandent un mot de passe numérique à 6 caractères que tu tapes avec un fake clavier visuel 😱

@CapsLock
Clairement ça me fait chier de faire ça ou même d'autoriser uniquement les adresses gmail par exemple ! Ça me fais d'autant plus chier que lorsque je suis sur un site qui fait exactement pareil je père un plomb devant ... Sûrement qu'un dev freelance a plus de possibilité qu'un dev dans une boite ou ton chef te dire de faire comme le client veut

@CapsLock @bortzmeyer plus simple:
$0.value=prompt()
$0 étant l'input sélectionné avec l'inspecteur du dom.

@CapsLock ok par contre tu devrais pas publier comme ça ton mot de passe, et probablement en choisir un plus robuste :thaenking:

@CapsLock Le problème est surtout lorsque la limite est trop basse, certains algorithmes de hachage sont limités en taille. Typiquement PASSWORD_BCRYPT de PHP ne permet pas de gérer les pass de plus de 72 caractères et ignore les caractères suivants. 72 caractères, il y a tout de même de quoi faire ! Même remarque pour certains caractères spéciaux et accents : le jour où il faut le taper sur un clavier Mac avec des combinaisons de touches auquel on est pas habitué 😣.

@CapsLock au sujet des mots de passe limités, il y a a dire: j'utilise a l'hôpital, un logiciel de prescriptions: il y a deux methodes pour se connecter (même id même mdp)
La première, c'est pas limité (ou pas a trop)
La seconde, est limité a 8.
Le plus marrant, c'est quand vous changez le mdp dans le premier -> ah! Trop long ça marche pas dans le second, pourtant pour faire la même chose !
Et ça gêne personne, comme c'est une boîte privée: pas de demande de correction

Sign in to participate in the conversation
social.cloudfrancois.fr

social.cloudfrancois.fr is one server in the network