Trate un número de conta secreto como unha credencial: audíteo

Un campo etiquetado como número de conta non é automaticamente unha referencia pública, e a etiqueta non é a proba. A proba é o que permite a posesión: se coñecer o número inicia a sesión de alguén, baixa un perfil de conexión ou autoriza un dispositivo, ese número é unha credencial cun ciclo de vida. Fago as cinco comprobacións seguintes sempre que un servizo emite unha identidade numérica e a cualifica de inofensiva. Cada unha produce unha liña nun rexistro breve, e o rexistro é o entregable, non un veredicto sobre o produto.

Inventarie o que concede realmente a posesión

Anote por separado cada acción que desbloquea o número. Iniciar sesión nun portal, obter un ficheiro de configuración, autorizar un dispositivo novo e fornecer un inicio de sesión de túnel aceptado son autoridades diferentes, e un servizo pode implementar unha sen as outras. Un portal que acepta o número como único campo non di nada sobre como o túnel autentica o seu par máis tarde nin sobre como se derivan as claves de tráfico.

O modelo xeral é fácil de enunciar: unha credencial bearer é aquela que o titular pode usar sen demostrar a posesión dunha clave criptográfica separada, e esa é a distinción que RFC 6750 traza para os testemuños. É unha comparación, non a afirmación de que un servizo baseado nun número implemente OAuth. Se o titular non necesita nada máis, trate o número como un segredo bearer e clasifique o resto do deseño en consecuencia.

Protéxao como un segredo, non como unha referencia

O almacenamento deriva da clasificación. Un valor que inicia a sesión pertence a un xestor de contrasinais, non a unha captura de pantalla, un historial do portapapeis, unha mensaxe de chat ou unha nota do navegador. As capturas de pantalla son a fuga habitual: o número é curto e parece inofensivo, así que acaba nun fío de asistencia que sobrevive ao dispositivo de onde saíu.

O phishing é o outro modo de fallo, e non lle importa o aleatorio que sexa o número. Un impostor que quere o valor pediravos que o peguedes nun formulario, e unha credencial que nunca caduca e non ten segundo factor paga a pena. Chegade ao camiño de inicio de sesión desde un marcador ou un enderezo coñecido, non desde unha ligazón nunha mensaxe que tamén pide o número.

Trate o material de recuperación como parte do segredo. Se o operador tamén emitiu un código de recuperación, un PIN ou un enderezo de correo que pode restablecer a conta, son credenciais separadas co mesmo requisito de protección. Unha única canle de restablecemento desprotexida converte todos os demais controis en decoración.

Comprobe xuntas a resistencia á adiviñación e a limitación de taxa

A lonxitude só ten sentido xunto ao método de xeración. Un número longo producido por unha secuencia predicible é máis feble que un valor curto producido por un xerador criptográfico, e un número impresionante de díxitos non establece impredicibilidade. Preguntade como se xera o valor antes de razoar sobre o difícil que é adiviñalo.

A resistencia á adiviñación por si soa tampouco sobrevive a unha taxa de intentos ilimitada. Os controis que importan son os que implementa o operador: contadores de intentos fallidos, bloqueos, limitación por orixe e se un número incorrecto se pode distinguir dun inexistente. Se o servizo o admite, un intento fallido amósalles como é o erro e se aparece un contador de reintentos:

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

Rexistre o que revela a resposta. Un erro distinto para unha conta descoñecida é un oráculo de enumeración mesmo cando o número é imposible de adiviñar, e esa conclusión pertence ao rexistro, tanto se a podedes corrixir desde o cliente como se non.

Planifique a rotación e a revogación antes de necesitalas

Atopade o proceso admitido para un número perdido ou exposto e anotádeo mentres todo funciona. Pódese substituír a credencial da conta? A substitución invalida os dispositivos xa inscritos, as sesións activas ou a configuración descargada? Que material de recuperación esixe o proceso? Un servizo sen dependencia do correo pode trasladar máis responsabilidade de recuperación ao usuario, o que fai o procedemento máis importante, non menos.

Separe a substitución da conta da revogación da credencial. Se o número autoriza a descarga dunha clave, un certificado ou un perfil, substituír o número pode deixar válido ese material descargado, e revogar o material descargado pode ser outra operación con outro propietario. Non supoñades que un campo cambiado remata todas as conexións; comprobade o modelo real do operador e anotade onde o verificastes.

Documente a decisión e volva comprobalo máis adiante

Manteña un rexistro dunha páxina por servizo: que autoridades concede o número, onde se almacena, quen o pode restablecer, que probas de uso existen e que faríades na primeira hora tras unha revelación. Ese rexistro é o que converte unha discusión sobre terminoloxía nunha decisión que alguén pode auditar.

As afirmacións de privacidade necesitan o seu propio ámbito. Un número xerado aleatoriamente pode seguir sendo un identificador estable que liga acontecementos da conta ao longo do tempo; a impredicibilidade non é a non-ligazón, e ningunha das dúas propiedades di nada sobre os metadatos de rede conservados. Compare deseños completos en lugar de contar campos nunha pantalla de inicio de sesión.

Antes de rexistralo:

• Enuméranse todas as autoridades que concede o número, incluídas as descargas e a autorización de dispositivos.
• As canles de almacenamento e recuperación están protexidas co mesmo estándar que o propio número.
• O método de xeración e os límites de taxa coñécense, non se supoñen pola lonxitude.
• Existen un procedemento de substitución e un de revogación, e sabedes cal anula cal.
• O rexistro indica quen pode restablecer o valor e que probas quedan despois do uso.