4dim / Notas
Dos secretos para dos trabajos distintos
Un enlace secreto se pega; un código de referencia se lee, se teclea y a veces se dicta por teléfono. Por qué no se generan igual, por qué el alfabeto deja fuera la O y el cero, y cómo se calcula cuánto azar hace falta de verdad.
El mismo sistema, dos secretos distintos
Si en tu producto hay enlaces secretos, códigos de referencia o claves que alguien dicta por teléfono, esta nota te dice por qué no deben generarse todos igual. Es una decisión de diez minutos que evita dos clases de problema.
En nuestro sistema conviven dos identificadores que parecen lo mismo y no lo son:
- La dirección secreta de una página —un estudio, una invitación al equipo—. Larga, imposible de adivinar.
- La referencia corta que viaja dentro de un mensaje de WhatsApp, del estilo «4D-XXXXXX». Seis caracteres.
Uno se pega. El otro se lee, se teclea y a veces se dicta en voz alta. Esa diferencia lo cambia todo.
El que se pega: largo, y da igual que sea feo
La dirección de un estudio lleva 32 bytes de azar. Sale una cadena larga y sin sentido, y está bien que lo sea: nadie la va a teclear. Se copia y se pega.
Como no hay que escribirla, no hay ninguna razón para acortarla. Y sí hay una razón muy concreta para alargarla: quien acierte una dirección lee el nombre de un negocio ajeno junto a la lista de lo que hace mal. Eso no puede pasar ni por casualidad ni por fuerza bruta.
La regla general: cuando un secreto no se teclea, la comodidad no es un criterio y lo único que queda es la imposibilidad de adivinarlo. Los enlaces de invitación al equipo se generan igual, y por lo mismo.
El que se lee: corto, y sin caracteres tramposos
La referencia corta tiene el problema contrario. Viaja dentro de un mensaje que una persona puede reescribir, y a veces alguien la dicta por teléfono.
Así que el alfabeto deja fuera los caracteres que se confunden: la O y el cero; la I, la L y el uno. Quedan 31 símbolos.
| Fuera | Se confunde con | Dónde falla |
|---|---|---|
| O | 0 | Leyendo en pantalla |
| I | 1, L | En muchas tipografías |
| L | 1, I | Dictando en voz alta |
El motivo es más fuerte que la comodidad: una referencia que se copia mal no empareja, y quien la copió no tiene forma de saber por qué. No hay mensaje de error posible. El mensaje llega a la bandeja como si viniera de un desconocido, y se pierde el rastro.
Cuánto azar hace falta, de verdad
Seis caracteres sobre 31 símbolos son unos 887 millones de combinaciones. Suena poco al lado de los 32 bytes del otro, y es suficiente, por una razón que conviene saber calcular.
La referencia solo tiene que ser única dentro de un negocio, y el tope real es cuántos estudios manda un negocio en toda su vida: unos cientos, quizá unos miles. No compite contra el universo entero.
Y no es un secreto: no da acceso a nada. Si alguien adivina una referencia, lo único que consigue es que su mensaje se empareje con un estudio que no es suyo, cosa que no le sirve de nada.
La pregunta que hay que hacerse siempre es esta: ¿contra qué tiene que ser único, y qué consigue quien lo acierte? Con esas dos respuestas, el tamaño sale solo. Sin ellas, uno acaba poniendo 32 bytes en un código que hay que dictar por teléfono, o seis caracteres en una puerta que da acceso a datos ajenos.
Buscarla en un mensaje sin encontrar lo que no es
Cuando llega un mensaje, hay que encontrar la referencia dentro del texto. Y ahí aparece un detalle que parece pedante y evita emparejamientos falsos.
El patrón que la busca usa el alfabeto exacto —los 31 símbolos permitidos— y no «cualquier letra o número». Consecuencia: un texto que contenga algo como «4D-HOLAAA» no pasa por referencia, porque la O y la letra que sobra no están en el alfabeto.
Los caracteres prohibidos existen para que un código mal copiado no empareje. Aprovecharlos también al buscar hace que un código inventado tampoco se parezca a uno real. La misma decisión paga dos veces.
Y va anclada a los dos extremos, para que no empareje a medias dentro de una palabra más larga.
El choque que no va a pasar, y el reintento que igual está
Con 887 millones de combinaciones y unos cientos de estudios por negocio, dos referencias iguales no van a coincidir nunca.
Aun así, la base de datos lo impide con una restricción de unicidad, y el código reintenta hasta cinco veces si choca.
¿Por qué molestarse con algo que no va a pasar? Porque el día que pase, sin reintento, sería un error en la cara de quien estaba creando una ficha, sin explicación posible y sin forma de reproducirlo. Cinco líneas convierten un misterio irreproducible en nada.
Lo que la base impide tiene que tener una salida en el código. Si no, la garantía se paga con un error inexplicable.
Qué hacer entonces
- Clasifica tus identificadores por cómo viajan. Los que se pegan y los que se leen. No deben generarse igual.
- Si se pega, hazlo largo. No hay ningún coste en alargarlo y hay un riesgo real en acortarlo.
- Si se lee, quita la O, el 0, la I, la L y el 1. Pierdes muy poco espacio y te ahorras los emparejamientos que nunca ocurren.
- Pregúntate contra qué tiene que ser único. Casi nunca es contra el universo; casi siempre es contra un cliente.
- Pon el reintento aunque la colisión sea imposible. Cuesta cinco líneas y evita un error que nadie podría reproducir.
Esta nota sale de nuestro trabajo en Desarrollo de Software a medida.