On va el codi de repte estàtic en un inici de sessió OpenVPN

El client mostra una segona caixa després del camp de contrasenya, escriviu el codi del testimoni de maquinari i l’inici de sessió continua fallant amb un error d’autenticació. Aquesta caixa existeix, així que el perfil la va demanar. Si el servidor va arribar a rebre el valor en una forma que entén és una altra pregunta, i és la que val la pena respondre primer.

Comenceu per l’indicador que el vostre client mostra realment

Un perfil pot portar una directiva de repte estàtic amb una cadena d’indicador i una bandera que controla si la resposta es mostra mentre escriviu. L’indicador és el que veieu al diàleg; la bandera és una preferència de visualització per a aquesta mateixa entrada. Cap dels dos diu al servidor com verificar res.

Compteu els camps que realment us han donat. Un camp per al nom d’usuari més un camp emmascarat és un inici de sessió normal amb contrasenya i sense cap repte. Un segon camp que apareix després de la contrasenya, amb la seva pròpia etiqueta, és el client implementant la interacció del repte.

Si la segona caixa no apareix mai al client que feu servir, potser aquell client no implementa la interacció, o només la implementa a través d’una interfície diferent, com una interfície de gestió. Comprovar el client és més barat que reescriure el perfil, i normalment és on hi ha realment la discrepància.

Què ha de suportar ja el servidor

El perfil descriu què ha de recollir el client. No activa la verificació al servidor, i un servidor sense la integració d’autenticació corresponent simplement rebrà una contrasenya que no reconeix. Per això alguns desplegaments mostren l’indicador i rebutgen tots els codis, i per això la resposta de l’operador sobre quin mecanisme fa la comprovació és la que importa.

Pregunteu a l’operador quin mecanisme fa la comprovació. Pot ser un connector que parla amb PAM, un ganxo d’escript que valida la resposta contra un servei de testimonis, o una integració basada en gestió que analitza ella mateixa el valor empaquetat. Cadascun espera una entrada una mica diferent.

Aquí també cal calibrar les expectatives. Un segon indicador és un mecanisme d’entrada, no la prova que s’apliqui un segon factor, perquè l’aplicació passa al costat del servidor i només es nota quan proveu un codi incorrecte.

El camp codificat que envia la interfície de gestió

Quan una interfície frontal impulsa la connexió a través de la interfície de gestió, la contrasenya i la resposta al repte s’empaqueten en un sol valor abans de l’enviament. La referència de la interfície de gestió documenta el format: un prefix i després la contrasenya i la resposta com a components Base64 separats.

Base64 és una codificació, no una protecció. No amaga res a qui pugui llegir el camp, i no converteix un codi d’un sol ús en una cosa reutilitzable. El valor empaquetat mereix el mateix tracte que una contrasenya: fora dels perfils compartits, fora de les línies d’ordres i fora dels registres de diagnòstic.

Aquesta codificació també és la font de confusió més habitual, perquè ara hi ha tres formes que semblen iguals i no són intercanviables. Un fitxer de credencials simple conté una contrasenya. Una concatenació literal de contrasenya i codi conté una cadena diferent. La resposta empaquetada d’un client de gestió conté una tercera. Confirmeu quina espera el vostre camí de verificació abans de canviar un camp només perquè ha desaparegut un error.

Estàtic contra dinàmic: moment diferent

Un repte estàtic es coneix abans que s’enviï la primera credencial, així que el client el pot demanar per endavant. Un repte dinàmic arriba més tard, enviat pel flux d’autenticació després que ja hagi començat un intercanvi, i necessita un client que sàpiga gestionar una petició a mig diàleg.

El suport d’un no us dona l’altre. Una directiva de perfil que configura un indicador estàtic no implementa un repte iniciat pel servidor, i una interfície frontal que gestiona peticions dinàmiques pot no mostrar encara un d’estàtic. Llegir quin costat ha iniciat la petició és la manera més ràpida de distingir-los.

El funcionament desatès és on això es converteix en una qüestió de disseny i no d’interfície. Un codi desat no és una credencial duradora d’arrencada, i una reconnexió hores després necessitarà una entrada nova tret que el desplegament admeti una disposició de testimonis que l’operador hagi activat deliberadament.

Proveu l’èxit i el fracàs, no només el diàleg

Executeu les dues meitats de la prova. Unes credencials correctes amb una resposta vàlida haurien de passar; unes credencials correctes amb una resposta deliberadament incorrecta haurien de ser rebutjades. Si totes dues passen, el client recull una entrada que res no verifica, i el diàleg s’ha confós amb un control. Aquesta única prova detecta més desplegaments que qualsevol revisió de perfil.

Després repetiu la connexió després d’una reconnexió, amb un compte que no estigui inscrit i a través del client que els vostres usuaris facin servir realment. Que aparegui l’indicador és un comportament del client; que es rebutgi un codi incorrecte és el servidor aplicant alguna cosa.