Qu'une personne ayant l'auth code puisse le transférer. -- oui mais bon les choses changent, évoluent, les DSLAM se connaissent mieux maintenant, sont plus des étrangers les uns pour les autres, z'ont plus forcément envie de faire chambre à part :-) -+- Brina in GFD - "Rapprochement stratégique" -+-
Olivier Masson <sisemen@laposte.net> a couché sur son écran le
07/05/2007 15:11:50 +0200 :
Bonjour,
que risque-t-on si le status d'un nom de domaine est simplement 'Ok'
plutôt que :
Qu'une personne ayant l'auth code puisse le transférer.
--
oui mais bon les choses changent, évoluent, les DSLAM se connaissent
mieux maintenant, sont plus des étrangers les uns pour les autres,
z'ont plus forcément envie de faire chambre à part :-)
-+- Brina in GFD - "Rapprochement stratégique" -+-
Qu'une personne ayant l'auth code puisse le transférer. -- oui mais bon les choses changent, évoluent, les DSLAM se connaissent mieux maintenant, sont plus des étrangers les uns pour les autres, z'ont plus forcément envie de faire chambre à part :-) -+- Brina in GFD - "Rapprochement stratégique" -+-
Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Monsieur 99
Patrick Mevzek a couché sur son écran le 07/05/2007 17:39:42 +0200 :
Status: clientDeleteProhibited Status: clientTransferProhibited Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Effectivement :-)
--
à dos de Mule ? Ben euh, ils y sont allés avec ma femme, mais je pense que c'est la
voiture qui transportait, donc la réponse est "non" ;-) -+- SC in GFD - "Macho ? Vue de l'esprit, toussa..." -+-
Patrick Mevzek <pm-N200705@nospam.dotandco.com> a couché sur son écran
le 07/05/2007 17:39:42 +0200 :
Status: clientDeleteProhibited
Status: clientTransferProhibited
Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».
Effectivement :-)
--
à dos de Mule ?
Ben euh, ils y sont allés avec ma femme, mais je pense que c'est la
voiture qui transportait, donc la réponse est "non" ;-)
-+- SC in GFD - "Macho ? Vue de l'esprit, toussa..." -+-
Patrick Mevzek a couché sur son écran le 07/05/2007 17:39:42 +0200 :
Status: clientDeleteProhibited Status: clientTransferProhibited Qu'une personne ayant l'auth code puisse le transférer.
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Effectivement :-)
--
à dos de Mule ? Ben euh, ils y sont allés avec ma femme, mais je pense que c'est la
voiture qui transportait, donc la réponse est "non" ;-) -+- SC in GFD - "Macho ? Vue de l'esprit, toussa..." -+-
Olivier Masson
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Monsieur 99
Olivier Masson a couché sur son écran le 07/05/2007 20:05:42 +0200 :
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Depuis l'introduction de l'auth code, oui. Avant, un petit peu moins.
--
Pourquoi faut'il tout ce temps? Restriction de budget .. Ils amenent le materiel au central a dos de
chameau (et il faut le temps de trouver le chameau) -+- Spyou in GFD - "Ils dégroupent toujours en Egypte" -+-
Olivier Masson <sisemen@laposte.net> a couché sur son écran le
07/05/2007 20:05:42 +0200 :
Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Depuis l'introduction de l'auth code, oui. Avant, un petit peu moins.
--
Pourquoi faut'il tout ce temps?
Restriction de budget .. Ils amenent le materiel au central a dos de
chameau (et il faut le temps de trouver le chameau)
-+- Spyou in GFD - "Ils dégroupent toujours en Egypte" -+-
Olivier Masson a couché sur son écran le 07/05/2007 20:05:42 +0200 :
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Depuis l'introduction de l'auth code, oui. Avant, un petit peu moins.
--
Pourquoi faut'il tout ce temps? Restriction de budget .. Ils amenent le materiel au central a dos de
chameau (et il faut le temps de trouver le chameau) -+- Spyou in GFD - "Ils dégroupent toujours en Egypte" -+-
Patrick Mevzek
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Ce qui été du pipeau c'était de faire croire que le code d'authentification allait résoudre tous les problèmes de transfert, alors qu'on est dans le cas typique d'un problème nécessitant un compromis puisqu'on a dans la balance d'un côté de limiter les transferts frauduleux, de l'autre de faciliter la mobilité entre bureaux.
L'affaire RegisterFly illustre d'ailleurs bien la difficulté de faire des transferts maintenant à cause de ce code (que le bureau doit donner). A noter qu'on constate là une certaine impédance entre ce qui était prévu au niveau des concepteurs du protocole EPP (qui pensaientt que le code serait choisi lors de l'enregistrement du nom de domaine - rarement le cas - et aisément accessible voire modifiable par le « propriétaire » du domaine) et ce qu'on a vu en pratique (les catastrophes initiales allaient même jusqu'à certains bureaux d'enregistrement qui utilisaient un seul et même code pour tous les domaines qu'ils géraient !).
De nos jours, un bureau d'enregistrement ne peut pas démarrer le transfert (au sens de la commande à envoyer au registre) sans la possession de ce code, ce qui n'est donc pas toujours facile à obtenir. Plusieurs registres caressent l'idée de pouvoir envoyer ce code directement, en court-circuitant le bureau d'enregistrement : c'est possible puisque tous les nouveaux gTLDs stockent les informations personnelles (donc en particulier les adresses email des contacts et propriétaire) au niveau du registre.
A noter que certains bureaux d'enregistrement sont très enclins à mettre automatiquement un état clientTransferProhibited sur tout nom de domaine ... et pas forcément aussi enclins à faciliter au propriétaire du domaine de pouvoir enlever cet état.
Quant au clientDeleteProhibited on va dire que cela permet surtout d'éviter les _grosses_ bourdes du bureau d'enregistrement au niveau d'une suppression accidentelle, puisque cet état nécessitera alors obligatoirement deux opérations (une mise à jour pour enlever cet état, puis la destruction en elle-même), qui ne peuvent pas être cumulées en une seule opération en EPP.
Bref, il n'y a aucune solution magique. Le cas idéal c'est le bureau d'enregistrement qui permet facilement à son client d'ajouter ou d'enlever les états qu'il souhaite (avec un minimum d'explications). _Dans ce cas de figure_, avoir clientDeleteProhibited et clientTransferProhibited est une bonne chose (avec le postulat initial, pas de conséquences négatives) ... mais certainement pas une protection infaillible, donc on peut aussi vivre sans.
Si votre bureau d'enregistrement ne vous permet pas de contrôler ces états aisément, cela peut aussi être un élément de choix quant à poursuivre la prestation avec lui.
A noter que là comme ailleurs, quand on veut vérifier il vaut mieux regarder directement le whois du registre (whois qui maintenant exhibe les états EPP, avec quelques modulations, tous les registres n'ayant pas mis en oeuvre la même version du standard EPP) et pas le whois du bureau d'enregistrement qui peut montrer des états fantômes ou internes (cuisine interne du bureau non nécessairement répercutée chez le registre).
Voilà pour ma tartine post-élections :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si cette personne a récupéré cette information elle a probablement
déjà accès au compte chez le bureau d'enregistrement... qui permettra
d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Ce qui été du pipeau c'était de faire croire que le code
d'authentification allait résoudre tous les problèmes de transfert,
alors qu'on est dans le cas typique d'un problème nécessitant un
compromis puisqu'on a dans la balance d'un côté de limiter les
transferts frauduleux, de l'autre de faciliter la mobilité entre bureaux.
L'affaire RegisterFly illustre d'ailleurs bien la difficulté de faire des
transferts maintenant à cause de ce code (que le bureau doit donner). A
noter qu'on constate là une certaine impédance entre ce qui était
prévu au niveau des concepteurs du protocole EPP (qui pensaientt que le
code serait choisi lors de l'enregistrement du nom de domaine - rarement
le cas - et aisément accessible voire modifiable par le « propriétaire
» du domaine) et ce qu'on a vu en pratique (les catastrophes initiales
allaient même jusqu'à certains bureaux d'enregistrement qui utilisaient
un seul et même code pour tous les domaines qu'ils géraient !).
De nos jours, un bureau d'enregistrement ne peut pas démarrer le
transfert (au sens de la commande à envoyer au registre) sans la
possession de ce code, ce qui n'est donc pas toujours facile à obtenir.
Plusieurs registres caressent l'idée de pouvoir envoyer ce code
directement, en court-circuitant le bureau d'enregistrement : c'est
possible puisque tous les nouveaux gTLDs stockent les informations
personnelles (donc en particulier les adresses email des contacts et
propriétaire) au niveau du registre.
A noter que certains bureaux d'enregistrement sont très enclins à mettre
automatiquement un état clientTransferProhibited sur tout nom de domaine
... et pas forcément aussi enclins à faciliter au propriétaire du
domaine de pouvoir enlever cet état.
Quant au clientDeleteProhibited on va dire que cela permet surtout
d'éviter les _grosses_ bourdes du bureau d'enregistrement au niveau
d'une suppression accidentelle, puisque cet état nécessitera alors
obligatoirement deux opérations (une mise à jour pour enlever cet état,
puis la destruction en elle-même), qui ne peuvent pas être cumulées en
une seule opération en EPP.
Bref, il n'y a aucune solution magique. Le cas idéal c'est le bureau
d'enregistrement qui permet facilement à son client d'ajouter ou
d'enlever les états qu'il souhaite (avec un minimum d'explications).
_Dans ce cas de figure_, avoir clientDeleteProhibited et
clientTransferProhibited est une bonne chose (avec le postulat
initial, pas de conséquences négatives) ... mais certainement pas une
protection infaillible, donc on peut aussi vivre sans.
Si votre bureau d'enregistrement ne vous permet pas de contrôler ces
états aisément, cela peut aussi être un élément de choix quant à
poursuivre la prestation avec lui.
A noter que là comme ailleurs, quand on veut vérifier il vaut mieux
regarder directement le whois du registre (whois qui maintenant exhibe les
états EPP, avec quelques modulations, tous les registres n'ayant pas mis
en oeuvre la même version du standard EPP) et pas le whois du bureau
d'enregistrement qui peut montrer des états fantômes ou internes
(cuisine interne du bureau non nécessairement répercutée chez le
registre).
Voilà pour ma tartine post-élections :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si cette personne a récupéré cette information elle a probablement déjà accès au compte chez le bureau d'enregistrement... qui permettra d'enlever ces deux « protections ».
Donc c'est un peu du pipeau commercial ?
Ce qui été du pipeau c'était de faire croire que le code d'authentification allait résoudre tous les problèmes de transfert, alors qu'on est dans le cas typique d'un problème nécessitant un compromis puisqu'on a dans la balance d'un côté de limiter les transferts frauduleux, de l'autre de faciliter la mobilité entre bureaux.
L'affaire RegisterFly illustre d'ailleurs bien la difficulté de faire des transferts maintenant à cause de ce code (que le bureau doit donner). A noter qu'on constate là une certaine impédance entre ce qui était prévu au niveau des concepteurs du protocole EPP (qui pensaientt que le code serait choisi lors de l'enregistrement du nom de domaine - rarement le cas - et aisément accessible voire modifiable par le « propriétaire » du domaine) et ce qu'on a vu en pratique (les catastrophes initiales allaient même jusqu'à certains bureaux d'enregistrement qui utilisaient un seul et même code pour tous les domaines qu'ils géraient !).
De nos jours, un bureau d'enregistrement ne peut pas démarrer le transfert (au sens de la commande à envoyer au registre) sans la possession de ce code, ce qui n'est donc pas toujours facile à obtenir. Plusieurs registres caressent l'idée de pouvoir envoyer ce code directement, en court-circuitant le bureau d'enregistrement : c'est possible puisque tous les nouveaux gTLDs stockent les informations personnelles (donc en particulier les adresses email des contacts et propriétaire) au niveau du registre.
A noter que certains bureaux d'enregistrement sont très enclins à mettre automatiquement un état clientTransferProhibited sur tout nom de domaine ... et pas forcément aussi enclins à faciliter au propriétaire du domaine de pouvoir enlever cet état.
Quant au clientDeleteProhibited on va dire que cela permet surtout d'éviter les _grosses_ bourdes du bureau d'enregistrement au niveau d'une suppression accidentelle, puisque cet état nécessitera alors obligatoirement deux opérations (une mise à jour pour enlever cet état, puis la destruction en elle-même), qui ne peuvent pas être cumulées en une seule opération en EPP.
Bref, il n'y a aucune solution magique. Le cas idéal c'est le bureau d'enregistrement qui permet facilement à son client d'ajouter ou d'enlever les états qu'il souhaite (avec un minimum d'explications). _Dans ce cas de figure_, avoir clientDeleteProhibited et clientTransferProhibited est une bonne chose (avec le postulat initial, pas de conséquences négatives) ... mais certainement pas une protection infaillible, donc on peut aussi vivre sans.
Si votre bureau d'enregistrement ne vous permet pas de contrôler ces états aisément, cela peut aussi être un élément de choix quant à poursuivre la prestation avec lui.
A noter que là comme ailleurs, quand on veut vérifier il vaut mieux regarder directement le whois du registre (whois qui maintenant exhibe les états EPP, avec quelques modulations, tous les registres n'ayant pas mis en oeuvre la même version du standard EPP) et pas le whois du bureau d'enregistrement qui peut montrer des états fantômes ou internes (cuisine interne du bureau non nécessairement répercutée chez le registre).
Voilà pour ma tartine post-élections :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Olivier Masson
Voilà pour ma tartine post-élections :-)
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
Voilà pour ma tartine post-élections :-)
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
de base, le mail d'alerte pour le renouvellement de domaine est envoyé
aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social
engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep :
un petit coup de snif et hop, on a le mot de passe. Car personne (à part
mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le
chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
comme protection, non ?
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
Spyou
Voilà pour ma tartine post-élections :-)
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick me corrigera le cas echeant :)) aucune obliation en ce sens (envoi d'email pour confirmation des contacts avant transfert)
Voilà pour ma tartine post-élections :-)
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
de base, le mail d'alerte pour le renouvellement de domaine est envoyé
aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social
engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep :
un petit coup de snif et hop, on a le mot de passe. Car personne (à part
mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le
chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick
me corrigera le cas echeant :)) aucune obliation en ce sens (envoi
d'email pour confirmation des contacts avant transfert)
C'est très bien ainsi (enfin, pas en ce qui concerne les élections).
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick me corrigera le cas echeant :)) aucune obliation en ce sens (envoi d'email pour confirmation des contacts avant transfert)
Patrick Mevzek
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick me corrigera le cas echeant :)) aucune obliation en ce sens (envoi d'email pour confirmation des contacts avant transfert)
Depuis 2004 et la nouvelle politique de transfert (<http://www.icann.org/transfers/policy-12jul04.htm>) il est à la charge exclusive du nouveau bureau de s'assurer d'avoir l'accord des contacts (administratif ou propriétaire, cf §2.1) et il n'a pas le droit de lancer un transfert sans cet accord.
Le bureau perdant peut alerter les contacts qu'un transfert a lieu et demander confirmation, mais n'y est pas tenu via un document spécifique (<http://www.icann.org/transfers/foa-conf-12jul04.htm>). A noter que l'accord est le comportement par défaut, sous 5 jours.
Ce désaccord possible des contacts via le bureau actuel est l'une des neuf causes possibles de rejet. L'absence de réponse est explicitement interdite comme cause de rejet possible.
A noter que cette nouvelle politique a été mise en place avant l'utilisation des codes d'authentification partout, et donc l'ensemble actuellement est plutôt un goubli boulga pas très cohérent. Mais au moins ca clarifie les voies de résolution des litiges, ca c'est bien.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger
comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick
me corrigera le cas echeant :)) aucune obliation en ce sens (envoi
d'email pour confirmation des contacts avant transfert)
Depuis 2004 et la nouvelle politique de transfert
(<http://www.icann.org/transfers/policy-12jul04.htm>) il est à
la charge exclusive du nouveau bureau de s'assurer d'avoir l'accord des
contacts (administratif ou propriétaire, cf §2.1) et il n'a pas le droit
de lancer un transfert sans cet accord.
Le bureau perdant peut alerter les contacts qu'un transfert a lieu et
demander confirmation, mais n'y est pas tenu via un document spécifique
(<http://www.icann.org/transfers/foa-conf-12jul04.htm>). A noter que
l'accord est le comportement par défaut, sous 5 jours.
Ce désaccord possible des contacts via le bureau actuel est l'une des
neuf causes possibles de rejet. L'absence de réponse est explicitement
interdite comme cause de rejet possible.
A noter que cette nouvelle politique a été mise en place avant
l'utilisation des codes d'authentification partout, et donc l'ensemble
actuellement est plutôt un goubli boulga pas très cohérent.
Mais au moins ca clarifie les voies de résolution des litiges, ca c'est
bien.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
D'autant que les bureaux d'enregistrement n'ont (il me semble, Patrick me corrigera le cas echeant :)) aucune obliation en ce sens (envoi d'email pour confirmation des contacts avant transfert)
Depuis 2004 et la nouvelle politique de transfert (<http://www.icann.org/transfers/policy-12jul04.htm>) il est à la charge exclusive du nouveau bureau de s'assurer d'avoir l'accord des contacts (administratif ou propriétaire, cf §2.1) et il n'a pas le droit de lancer un transfert sans cet accord.
Le bureau perdant peut alerter les contacts qu'un transfert a lieu et demander confirmation, mais n'y est pas tenu via un document spécifique (<http://www.icann.org/transfers/foa-conf-12jul04.htm>). A noter que l'accord est le comportement par défaut, sous 5 jours.
Ce désaccord possible des contacts via le bureau actuel est l'une des neuf causes possibles de rejet. L'absence de réponse est explicitement interdite comme cause de rejet possible.
A noter que cette nouvelle politique a été mise en place avant l'utilisation des codes d'authentification partout, et donc l'ensemble actuellement est plutôt un goubli boulga pas très cohérent. Mais au moins ca clarifie les voies de résolution des litiges, ca c'est bien.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Chez la majorité des bureaux oui, probablement. Ce n'est certes pas la seule façon de faire.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Il y a encore plus simple avec un peu de patience : on cherche les domaines dont les contacts ont des adresses email sur des domaines non renouvelés, ce qui arrive régulièrement. On redépose après le nom de domaine en question et on récupère donc le contrôle de toutes les adresses email et donc le contrôle de tous les domaine ayant des contacts avec ces adresses email. Ou on contacte le bureau en disant que les emails répondent pas, et le bureau va détruire le domaine ... qu'on peut donc récupérer après (d'autant plus probablement que le bureau met en vente aux enchéres les domaines).
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
La sécurité de la majorité des noms de domaine actuellement est effectivement au niveau de la sécurité des adresses email des contacts, compte-tenu des choix opérés par la majorité des bureaux. Mais il y a d'autres façons de faire :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que,
de base, le mail d'alerte pour le renouvellement de domaine est envoyé
aux mails que l'on a pour l'admin et facturation.
Chez la majorité des bureaux oui, probablement. Ce n'est certes pas la
seule façon de faire.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social
engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep
: un petit coup de snif et hop, on a le mot de passe. Car personne (à
part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le
chiffrement du mot de passe.
Il y a encore plus simple avec un peu de patience : on cherche les
domaines dont les contacts ont des adresses email sur des domaines non
renouvelés, ce qui arrive régulièrement. On redépose après le nom de
domaine en question et on récupère donc le contrôle de toutes les
adresses email et donc le contrôle de tous les domaine ayant des contacts
avec ces adresses email.
Ou on contacte le bureau en disant que les emails répondent pas, et le
bureau va détruire le domaine ... qu'on peut donc récupérer après
(d'autant plus probablement que le bureau met en vente aux enchéres les
domaines).
Vu ce que peut parfois représenter un nom de domaine, c'est un peu
léger comme protection, non ?
La sécurité de la majorité des noms de domaine actuellement est
effectivement au niveau de la sécurité des adresses email des contacts,
compte-tenu des choix opérés par la majorité des bureaux. Mais il y a
d'autres façons de faire :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Ce qui m'effraie surtout pour les domaines, c'est qu'il me semble que, de base, le mail d'alerte pour le renouvellement de domaine est envoyé aux mails que l'on a pour l'admin et facturation.
Chez la majorité des bureaux oui, probablement. Ce n'est certes pas la seule façon de faire.
Donc en regardant le whois, on a le mail. Ensuite, un peu de social engineering et voilà. Au mieux, on a l'adresse et ils sont en wifi wep : un petit coup de snif et hop, on a le mot de passe. Car personne (à part mes clients :)) n'utilise du pop/smtp sécurisé ou, au moins, le chiffrement du mot de passe.
Il y a encore plus simple avec un peu de patience : on cherche les domaines dont les contacts ont des adresses email sur des domaines non renouvelés, ce qui arrive régulièrement. On redépose après le nom de domaine en question et on récupère donc le contrôle de toutes les adresses email et donc le contrôle de tous les domaine ayant des contacts avec ces adresses email. Ou on contacte le bureau en disant que les emails répondent pas, et le bureau va détruire le domaine ... qu'on peut donc récupérer après (d'autant plus probablement que le bureau met en vente aux enchéres les domaines).
Vu ce que peut parfois représenter un nom de domaine, c'est un peu léger comme protection, non ?
La sécurité de la majorité des noms de domaine actuellement est effectivement au niveau de la sécurité des adresses email des contacts, compte-tenu des choix opérés par la majorité des bureaux. Mais il y a d'autres façons de faire :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
