Este artículo o sección necesita referencias que aparezcan en una publicación acreditada. Busca fuentes: «Autenticación» – noticias · libros · académico · imágenes Este aviso fue puesto el 5 de junio de 2018.

La autenticación o autentificación^[1]​ es el acto o proceso de confirmar que algo (o alguien) es quien dice ser. A la parte que se identifica se le llama probador. A la parte que verifica la identidad se la llama verificador. Es habitual que el probador sea un usuario que quiere acceder a ciertos recursos y el verificador sea un sistema que protege el acceso a dichos recursos y tiene que verificar que el que accede sea un usuario que tiene permisos para acceder a esos recursos. Para poder tener autenticación es necesaria, como condición previa, la existencia de identidades biunívocamente identificadas de tal forma que se permita hacer la tarea

La autenticación o autentificación (palabra preferida por la RAE^[2]​) o mejor dicho acreditación, en términos de seguridad de redes de datos, se puede considerar uno de los tres pasos fundamentales (AAA). Cada uno de ellos es, de forma ordenada:

• Autenticación. En la seguridad de ordenador, la autenticación es el proceso de intento de verificar la identidad digital del remitente de una comunicación como una petición para conectarse. El remitente autenticado puede ser una persona que usa un ordenador, un ordenador por sí mismo o un programa del ordenador. En un web de confianza, "autenticación" es un modo de asegurar que los usuarios son quien ellos dicen que son; que el usuario que intenta realizar funciones en un sistema está autorizado para hacerlo.

• Autorización. Proceso por el cual la red de datos autoriza al usuario identificado a acceder a determinados recursos de la misma.

• Auditoría, mediante la cual la red o sistemas asociados registran todos y cada uno de los accesos a los recursos que realiza el usuario autorizados o no.

A menudo, el problema de la autorización es idéntico al de la autenticación; muchos protocolos de seguridad extensamente adoptados estándar, regulaciones obligatorias, y hasta estatutos se basan en esta suposición. Sin embargo, el uso más exacto describe la autenticación como el proceso de verificar la identidad de una persona, mientras que la autorización es el proceso de verificación de que una persona conocida tiene la autoridad para realizar cierta operación. La autenticación, por lo tanto, debe preceder la autorización.^{[cita requerida]}

Para distinguir la autenticación de la autorización de término estrechamente relacionada, existen unas notaciones de taquigrafía, que son: A1 para la autenticación y A2 para la autorización, que se usan con cierta frecuencia. También existen los términos AuthN y AuthZ, que se usan en algunas comunidades.^{[cita requerida]}

Garantiza que los participantes en una comunicación son los que dicen ser. Es decir, es un proceso de demostración de identidad de una parte ante las demás, de una manera fehaciente.

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada. Busca fuentes: «Autenticación» – noticias · libros · académico · imágenes Puedes avisar al redactor principal pegando lo siguiente en su página de discusión: {{sust:Aviso referencias|Autenticación}} ~~~~ Uso de esta plantilla: {{Referencias|t={{sust:CURRENTTIMESTAMP}}}}

Garantiza la autenticidad del origen de los datos, es decir, que provengan de donde deben provenir.

Los métodos de autenticación usados dependen de los que se utilizan para la verificación, y estos se dividen en cinco categorías:

• Sistemas basados en algo conocido. Ejemplo, una contraseña/password (Unix) o frase de contraseña/passphrase (PGP).
• Sistemas basados en algo poseído. Ejemplo, una tarjeta de identidad, una tarjeta inteligente(smartcard), un dispositivo usb tipo epass token, una tarjeta de coordenadas, una smartcard o un dongle criptográfico.
• Sistemas basados en una característica física del usuario o un acto involuntario del mismo. Por ejemplo, verificación de voz, verificación de escritura, verificación de huellas, verificación de patrones oculares.
• Sistemas basados en el comportamiento. Por ejemplo, la forma de teclear, de caminar, etcétera.
• Sistemas basados en la ubicación. Por ejemplo, el lugar, la dirección IP donde se realiza la acción, la hora específica, etcétera.

También puede ser

Directa

En el proceso de autenticación solo intervienen las partes interesadas o que se van a autenticar.

Indirecta

En el proceso interviene una tercera parte confiable que actúa como autoridad o juez, que avala la identidad de las partes involucradas.

Unilateral

Solo una parte se auténtica ante la otra. La otra parte no se auténtica ante la primera.

Mutua

Ambas partes deben autenticarse entre sí.

Cualquier sistema de identificación ha de poseer unas determinadas características para ser viable:

• Ha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas de fallo de en los sistemas menos seguros)....
• Económicamente factible para la organización (si su precio es superior al valor de lo que se intenta proteger, tenemos un sistema incorrecto).
• Soportar con éxito cierto tipo de ataques.
• Ser aceptable para los usuarios, que serán al fin y al cabo quienes lo utilicen.
• Respuesta inmediata, directa, inteligente, sencilla, ante cada situación.

Para autenticar, es necesario establecer un protocolo de comunicación entre las partes, de forma que la parte verificadora suele verificar que la parte que se identifica (habitualmente un usuario) efectivamente es quien dice que es. En general, el proceso de autenticación consta de los siguientes pasos:

1. El probador solicita acceso a un sistema.
2. El verificador solicita al usuario que se autentique.
3. El probador aporta las credenciales que le identifican y permiten verificar la autenticidad de la identificación.
4. El verificador valida según sus reglas si las credenciales aportadas son suficientes para dar acceso al usuario o no.

Un ejemplo familiar es el control de acceso. Un sistema informático supuesto para ser utilizado solamente por aquellos autorizados, debe procurar detectar y excluir el desautorizado. El acceso a él por lo tanto es controlado generalmente insistiendo en un procedimiento de la autentificación para establecer con un cierto grado establecido de confianza la identidad del usuario, por lo tanto concediendo esos privilegios como puede ser autorizado a esa identidad. Los ejemplos comunes del control de acceso que implican la autenticación incluyen:

• Retirar de dinero de un cajero automático.
• Control de un computador remoto sin Internet.
• Uso de un sistema de banca por Internet.

Para intentar probar la identidad de un sujeto u objeto posible aplicar una o más pruebas que, si se aprueban, se han declarado previamente para ser suficientes proceder. El problema es determinarse qué pruebas son suficientes, y muchos tales son inadecuadas. Han sido muchos casos de tales pruebas que son engañadas con éxito; tienen por su falta demostrada, ineludible, ser inadecuadas. Mucha gente continúa mirando las pruebas -- y la decisión para mirar éxito en pasar -como aceptable, y para culpar su falta en “descuido” o “incompetencia” de parte de alguien. El problema es que la prueba fue supuesta para trabajar en la práctica -- no bajo condiciones ideales de ningún descuido o incompetencia

Los factores de la autenticación para los seres humanos se clasifican, generalmente, en cuatro casos:

• Algo que el usuario es (ejemplo, la huella digital o el patrón retiniano), la secuencia de ADN (hay definiciones clasificadas de cuál es suficiente), el patrón de la voz (otra vez varias definiciones), el reconocimiento de la firma, las señales bio-eléctricas únicas producidas por el cuerpo vivo, u otro identificador biométrico).
• Algo que el usuario tiene (ejemplo, tarjeta de la identificación, símbolo de la seguridad, símbolo del software o teléfono celular)
• Algo que el usuario sabe (ejemplo, una contraseña, una frase o un número de identificación personal (el PIN) del paso).
• Algo que el usuario hace (ejemplo, reconocimiento de voz, firma, o el paso).

y

• Autenticación mediante dos factores "algo que tengo" la llave + "algo que sé" un número de PIN (token criptográfico)
• Autenticación triple factor "algo que tengo" el dispositivo criptográfico + "algo que sé" una clave de autenticación tipo PIN (al token criptográfico) + "quién soy" la huella dactilar que me permite autenticar el dispositivo de forma unívoca.

Una combinación de métodos se utiliza a veces, ejemplo, una tarjeta de banco y un PIN, en este caso se utiliza el término “autenticación de dos factores”. Históricamente, las huellas digitales se han utilizado como el método más autoritario de autenticación, pero procesos legales recientes en los EE. UU. y a otra parte han levantado dudas fundamentales sobre fiabilidad de la huella digital. Otros métodos biométricos son prometedores (las exploraciones retinianas y de la huella digital son un ejemplo), pero han demostrado ser fácilmente engañados en la práctica. En un contexto de los datos de la computadora, se han desarrollado protocolos de desafío-respuesta que permiten el acceso si el que se quiere autenticar responde correctamente a un desafío propuesto por el verificador. Hay protocolos desafío-respuesta basados en algoritmos criptográficos llamándose protocolos criptográficos de desafío-respuesta. La seguridad de los protocolos criptográficos de desafío-respuesta se basa en la seguridad de los algoritmos criptográficos que usa.

La autenticación fue definida por Arnnei Speiser en 2003, mientras que la web basó el servicio que proporciona en la autenticación de usuarios finales que tienen acceso (Login) a un servicio de Internet. La autenticación es similar a la verificación de la tarjeta de crédito para los sitios web del comercio electrónico. La verificación es hecha por un servicio dedicado que reciba la entrada y devuelva la indicación del éxito o de fallo. Por ejemplo, un usuario final desea entrar en su sitio web. Él consigue entrar en una página web de la conexión que requiere para acceso, su identificación como usuario y una contraseña para los sitios asegurados y su contraseña a la vez. La información se transmite al servicio del eAuthentication como pregunta. Si el servicio responde exitosamente, se permite al usuario final entrar en el servicio de esa página web con sus privilegios de usuario.

En un sistema Unix habitual cada usuario posee un nombre de entrada al sistema o login y una clave o password; ambos datos se almacenan generalmente en el fichero /etc/passwd. Este archivo contiene una línea por usuario donde se indica la información necesaria para que los usuarios puedan conectar al sistema y trabajar en él, separando los diferentes campos mediante ':'.

Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por su nombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una persona de otra (o al menos a un usuario de otro) es el UID del usuario en cuestión; el login es algo que se utiliza principalmente para comodidad de las personas (obviamente es más fácil acordarse de un nombre de entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en varias máquinas, cada una con un UID diferente).

Para cifrar las claves de acceso de sus usuarios, el sistema operativo Unix emplea un criptosistema irreversible que utiliza la función estándar de C crypt, basada en el algoritmo DES. Para una descripción exhaustiva del funcionamiento de crypt. Esta función toma como clave los ocho primeros caracteres de la contraseña elegida por el usuario (si la longitud de esta es menor, se completa con ceros) para cifrar un bloque de texto en claro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo texto cifrado, se realiza una permutación durante el proceso de cifrado elegida de forma automática y aleatoria para cada usuario, basada en un campo formado por un número de 12 bits (con lo que conseguimos 4096 permutaciones diferentes) llamado salt. El cifrado resultante se vuelve a cifrar utilizando la contraseña del usuario de nuevo como clave, y permutando con el mismo salt, repitiéndose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero, obteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con el salt, pasan a constituir el campo password del fichero de contraseñas, usualmente /etc/passwd. Así, los dos primeros caracteres de este campo estarán constituidos por el salt y los 11 restantes por la contraseña cifrada.

Los ataques de texto cifrado escogido constituyen la principal amenaza al sistema de autenticación de Unix; a diferencia de lo que mucha gente cree, no es posible descifrar una contraseña, pero es muy fácil cifrar una palabra junto a un determinado salt, y comparar el resultado con la cadena almacenada en el fichero de claves. De esta forma, un atacante leerá el fichero /etc/passwd (este fichero ha de tener permiso de lectura para todos los usuarios si queremos que el sistema funcione correctamente), y mediante un programa adivinador (o crackeador) cifrará todas las palabras de un fichero denominado diccionario (un fichero ASCII con un gran número de palabras de cualquier idioma o campo de la sociedad: historia clásica, deporte, cantantes...), comparando el resultado obtenido en este proceso con la clave cifrada del fichero de contraseñas; si ambos coinciden, ya ha obtenido una clave para acceder al sistema de forma no autorizada.

Otro método cada día más utilizado para proteger las contraseñas de los usuarios el denominado Shadow Password u oscurecimiento de contraseñas. La idea básica de este mecanismo es impedir que los usuarios sin privilegios puedan leer el fichero donde se almacenan las claves cifradas.

En casi todas las implementaciones de Shadow Password actuales se suele incluir la implementación para otro mecanismo de protección de las claves denominado envejecimiento de contraseñas (Password Aging). La idea básica de este mecanismo es proteger los passwords de los usuarios dándoles un determinado periodo de vida: una contraseña solo va a ser válida durante un cierto tiempo, pasado el cual expirará y el usuario deberá cambiarla.

Realmente, el envejecimiento previene, más que problemas con las claves, problemas con la transmisión de estas por la red: cuando conectamos mediante mecanismos como telnet, ftp o rlogin a un sistema Unix, cualquier equipo entre el nuestro y el servidor puede leer los paquetes que enviamos por la red, incluyendo aquellos que contienen nuestro nombre de usuario y nuestra contraseña.

Algo por lo que se ha criticado el esquema de autenticación de usuarios de Unix es la longitud, para propósitos de alta seguridad, demasiado corta de sus claves; lo que hace años era poco más que un planteamiento teórico, actualmente es algo factible: sin ni siquiera entrar en temas de hardware dedicado, seguramente demasiado caro para la mayoría de atacantes, con un supercomputador es posible romper claves de Unix en menos de dos días.

Un método que aumenta la seguridad de nuestras claves frente a ataques de intrusos es el cifrado mediante la función conocida como bigcrypt() o crypt16(), que permite longitudes para las claves y los salts más largas que crypt y sin embargo, aunque se aumenta la seguridad de las claves, el problema que se presenta aquí es la incompatibilidad con las claves del resto de Unices que sigan utilizando crypt; este es un problema común con otras aproximaciones que también se basan en modificar el algoritmo de cifrado, cuando no en utilizar uno nuevo.

PAM (Pluggable Authentication Module) no es un modelo de autenticación en sí, sino que se trata de un mecanismo que proporciona una interfaz entre las aplicaciones de usuario y diferentes métodos de autenticación, tratando de esta forma de solucionar uno de los problemas clásicos de la autenticación de usuarios: el hecho de que una vez que se ha definido e implantado cierto mecanismo en un entorno, es difícil cambiarlo. Mediante PAM podemos comunicar a nuestra aplicaciones con los métodos de autenticación que deseemos de una forma transparente, lo que permite integrar las utilidades de un sistema Unix clásico (login, ftp, telnet...) con esquemas diferentes del habitual password: claves de un solo uso, biométricos, tarjetas inteligentes...

La gran mayoría de las aplicaciones de linux usan estos métodos (PAM) para autenticarse frente al sistema, ya que una aplicación preparada para PAM (PAM-aware) puede cambiar el mecanismo de autenticación que usa sin necesidad de recompilar los fuentes. Incluso se puede llegar a cambiar el sistema de autenticación local sin siquiera tocar las aplicaciones existentes.

PAM viene `de serie' en diferentes sistemas Unix, tanto libres como comerciales, y el nivel de abstracción que proporciona permite cosas tan interesantes como kerberizar nuestra autenticación (al menos la parte servidora) sin más que cambiar la configuración de PAM, que se encuentra bien en el fichero /etc/pam.conf o bien en diferentes archivos dentro del directorio /etc/pam.d/

PAM trabaja con cuatro tipos separados de tareas de administración: authentication, account, session, y password. La asociación del esquema de administración preferido con el comportamiento de la aplicación se hace mediante archivos de configuración. Las funciones de administración las hacen módulos que se especifican en el archivo de configuración. Más adelante se explicara brevemente la sintaxis del archivo de configuración ya que se va fuera del alcance de este artículo.

Cuando una aplicación preparada para PAM inicia, se activa su comunicación con la API de PAM. Entre otras cosas esto fuerza la lectura del archivo de configuración: /etc/pam.conf. Alternativamente puede ser que se inicie la lectura de los archivos de configuración bajo /etc/pam.d/ (cuando existe un archivo de configuración correcto bajo este directorio, se ignora el archivo /etc/pam.conf)

El archivo (/etc/pam.conf) está formado por una lista de reglas (típicamente una por línea). Cada regla es un conjunto de campos separados por espacios (los tres primeros son case-sensitives):

service type control module-path module-arguments

La sintaxis de los archivos bajo /etc/pam.d/ es igual salvo que no existe el campo "service". En este caso "service" es el nombre del archivo en el directorio /etc/pam.d/ (el nombre del archivo debe estar en minúsculas) Usualmente service es el nombre del servicio o aplicación comúnmente usado, ejemplo de esto son login, su y ssh.

type especifica a que grupo de administración está asociada la regla. Las entradas válidas son:

• account/cuenta: este módulo maneja la cuenta sin basarse en autenticación. Típicamente se usa para restringir/permitir el acceso a un servicio basado en la hora o quizás desde donde se loguea el usuario (ej.: root solo se puede loguear desde consola

• auth: provee mecanismo de autenticación (el usuario es quien dice ser).

• password/clave: este módulo es requerido para modificar la password del usuario.

• session/sesión: este módulo está asociado con hacer tareas previas y/o posteriores al inicio del servicio mismo (pueden ser cosas como montar un directorio, activar logueos, etc.).

El tercer campo control especifica que hacer si falla el control aplicado. Existen dos sintaxis para este campo, una sencilla de un campo y otra que especifica más de un campo dentro de corchetes rectos [] Para la básica, las opciones son:

• required/requerido: indica que esta regla debe ser exitosa, de lo contrario el usuario no es autorizado a correr el servicio. Si falla se devuelve el control al programa, pero antes se ejecutan todos los módulos.

• requisite/requisito: es como el required, pero devuelve el control al programa enseguida de fallar.

• sufficient/suficiente: Si este módulo se verifica, entonces (se devuelve) se le da el ok al programa y no se sigue verificando los otros módulos.

• optional/opcional: la falla o no de este módulo es solo importante si es el único existente.

El cuarto campo module-path especifica el path al módulo PAM asociado con la regla. Los módulos se encuentran en /lib/security.

El quinto campo module-arguments es un conjunto de cero o más argumentos pasados al módulo durante su invocación. Los argumentos varían según el módulo.

La configuración de los archivos de configuración bajo /etc/pam.d/ resulta ser más flexible (se evita tener una archivo único enorme). Bajo este directorio se puede encontrar el archivo de configuración personal de un servicio particular como ser ssh. La única diferencia entre la sintaxis del archivo /etc/pam.conf es que no existe el campo service.

• Autenticación y autorización
• Autenticación de usuarios