Autenticación sin una base de datos

Question

Autenticación sin una base de datos

#1 de Fleche (55 votos)
#2 de Mike Samuel (18 votos)
#3 de David (9 votos)
#4 de PressingOnAlways (2 votos)
#5 de Anudeep N Rao (-1 votos)

12

Me ha inspirado una pregunta en Revisión de código , que se reduce a: ¿Cuál es la forma correcta de autenticar a un usuario sin una base de datos?

¿Sería el mismo proceso exacto si almacenara las credenciales en una matriz, un archivo XML o solo un archivo de texto simple?

Por ejemplo , examinemos el siguiente código PHP:

$credentials = array(
    'UserA' => '$2y$10$PassForA',
    'UserB' => '$2y$10$PassForB'
);

$username = $_POST['username'];
$password = $_POST['password'];

if (isset($credentials[$username]) && password_verify($password, $credentials[$username])) {
    // Successfully authenticated
} else {
    // Permission denied
}

¿Es esta una forma perfectamente aceptable para almacenar credenciales? Si tuviéramos que tomar el nombre de usuario y la contraseña con hash de un archivo externo (XML / txt), ¿tendríamos que tratar las cosas de manera diferente?

web-application passwords authentication

pregunta Alex L 26.06.2014 - 03:11

fuente

5 respuestas

18

autenticación sin una base de datos

Voy a interpretar esto como significado

¿Es posible diseñar un sistema de desafío-respuesta que permite a principal ¿demuestra que son quienes dicen que son sin usar una cantidad de almacenamiento que se amplíe con el número de principales? Es decir. utilizando un almacenamiento que es O (1) w.r.t. el número de directores.

Una forma de autenticar a un principal es hacer que presenten algo que solo ellos o usted podrían saber. Si alguien lo sabe, y ese alguien no es usted, entonces son ellos :)

Firma criptográfica le permite generar cadenas (tokens) que

se lo puede dar a alguien
puedes olvidarlo
pueden devolverlo y usted puede verificar que realmente lo ha hecho usted

Si confía en que el principal de autenticación no filtre los secretos que controlan el acceso a su cuenta, puede darles un resultado firmado y usar la comprobación de firmas para autenticarlos.

Si no puedes confiar en que no filtren secretos, entonces no puedes confiar en que no filtren una contraseña que has introducido en tu base de datos de todos modos, por lo que existe la posibilidad de que usuarios ingenuos filtren un secreto que pueda ser reproducido. no es una razón para preferir contraseñas a firmar.

La comprobación de firmas simple no permite la revocación , pero eso es un problema de autorización, no estrictamente un problema de autenticación.

respondido por el Mike Samuel 26.06.2014 - 13:34

fuente

9

La autenticación de esa manera está bien, pero el verdadero truco es hacer la administración y las actualizaciones de su credencial. ¿Cómo cambian los usuarios sus contraseñas? ¿Estás reescribiendo tu fuente para hacer eso?

Ciertamente he visto las credenciales de autenticación almacenadas en archivos XML, JSON y CSV. Debe tomar medidas como adquirir un bloqueo al modificar el archivo, manejar bloqueos, etc., que normalmente se tratan con una base de datos.

respondido por el David 26.06.2014 - 03:16

fuente

2

Como referencia, el sistema de contraseñas de Unix se autentica de manera predeterminada en un archivo plano que no es una "base de datos" (/ etc / passwd y / etc / shadow). Tener una base de datos no se trata de seguridad sino de rendimiento. Cuando tienes que mirar a través de millones de líneas para encontrar al usuario JohnDoe, el rendimiento se ve afectado. Por otro lado, una base de datos bien indexada puede encontrar al mismo usuario casi al instante.

Esto también se aplica al almacenamiento de las credenciales del usuario directamente en una matriz: ¿cómo conservará los datos y cómo actualizará los registros si todo está codificado?

Ya que está preguntando en la página de seguridad, asumo que está preguntando cuáles son las mejores prácticas para almacenar una contraseña en un sistema de archivos sin formato. Bueno, la respuesta es la misma que si fuera un DB. Debes saltear y hash tus contraseñas para que, si alguna vez se compromete el archivo, nadie pueda aplicar ingeniería inversa a las contraseñas de todos.

respondido por el PressingOnAlways 26.06.2014 - 18:28

fuente

-1

La encapsulación de contraseñas utilizando el concepto OOP es mejor cuando se implementa a pequeña escala, donde el nombre de usuario y la contraseña con sal se envían a la función miembro de la clase que tiene la matriz de credenciales de usuario con el propósito de autenticación.

respondido por el Anudeep N Rao 03.10.2017 - 12:02

fuente

Lea otras preguntas en las etiquetas web-application passwords authentication

¿Una contraseña * adicional * para toda la empresa ofrece alguna seguridad real? Confusión: ¿Por qué no se autentica una clave SSH cifrada con frase de paso no?

score 55 · Accepted Answer

Un archivo XML con credenciales de usuario es una base de datos. La definición de una base de datos no se limita a MySQL (o lo que sea que tengas en mente).

La forma en que se autentican los usuarios y dónde se almacenan exactamente sus credenciales son dos preocupaciones completamente separadas. Un hash bcrypt es un hash bcrypt, independientemente de si está almacenado en un archivo de texto plano, una tabla MySQL o un documento MongoDB.

Por supuesto, los diferentes tipos de sistemas de bases de datos funcionan de manera diferente y requieren diferentes formas de actualizar y cargar datos, pero esto no tiene nada que ver con la autenticación del usuario específicamente. Esos son problemas generales de almacenamiento de datos.