La mayoría de las aplicaciones interactivas de Internet requieren que un usuario esté primero "registrado" para usar la aplicación y luego requiere que el usuario "inicie sesión" cada vez que desee usar la aplicación. Este proceso de inscribir primero a un usuario y luego reconocerlo para permitirle el acceso puede describirse como autenticación de usuario . Este artículo se centra en el código y los procesos utilizados en el componente de registro de nuestro sistema de autenticación de usuarios Authur .
Nuestro portal de inicio de sesión de demostración permite a los usuarios acceder a una aplicación de creación de cómics web llamada Storybook, pero el propio portal se puede emplear en muchas situaciones en las que se requiere autenticación para usar una aplicación web.
El código base que describimos a continuación está disponible en GitHub como repositorio público en https://github.com/Bob-Wright/Authur-User-Registration-System . Comentarios, críticas y sugerencias son siempre bienvenidos!
La aplicación del constructor se inicia desde una galería de historietas creadas por el propio constructor, y la primera página de la aplicación es la página de destino del portal de inicio de sesión que se muestra aquí en estas dos capturas de pantalla siguientes. Esta página es presentada por Portal.php en la carpeta Storybook.
Hay cuatro opciones de inicio de sesión enumeradas en nuestro cuadro de diálogo principal, junto con un modal emergente de explicación básica que describe cada una de las opciones de inicio de sesión disponibles a través del botón " OPCIONES DE INICIO DE SESIÓN EXPLICADAS ".
En el cuadro de diálogo de inicio de sesión también se incluye una opción para " Cambiar contraseña " que se incluye aquí porque un motivo frecuente por el que un usuario desea cambiar su contraseña es para poder iniciar sesión.
El último elemento del cuadro de diálogo es una invitación del botón Registrarse para registrarse como usuario.
Al seleccionar este botón Registrarse , se iniciará el programa signup.php y se nos presentará el cuadro de diálogo en las siguientes tres capturas de pantalla. Este cuadro de diálogo solicita información de datos de usuario que se utilizará para crear una entrada de base de datos de perfil de usuario
Además de obtener el nombre de usuario y la información de la dirección de correo electrónico, el cuadro de diálogo solicita el ingreso de una contraseña y, de acuerdo con la tradición, solicitamos una combinación de caracteres alfanuméricos en mayúsculas y minúsculas junto con al menos un carácter de símbolo. La intención de requerir estos parámetros de caracteres es obviamente hacer que la contraseña sea más difícil de adivinar. Lo bien que funciona es discutible.
Además de las entradas de nombre de usuario, correo electrónico y contraseña, el cuadro de diálogo también recopila ciertos elementos de datos sobre cada usuario. Estos elementos no contienen nominalmente datos de identificación personal, sino que están diseñados para proporcionar una breve lista de factores binarios (sí/no) que podemos usar más adelante en el proceso de validación. Entonces, por ejemplo, podríamos preguntarle a un usuario en particular "¿Sabes nadar?" como un factor para identificarlos.
Después de proporcionar estos elementos de datos, podemos continuar haciendo clic en el botón " Registrarse " en la parte inferior de la pantalla. Esto dará como resultado la siguiente pantalla que nos informa que se ha enviado un correo electrónico de confirmación al usuario.
El correo electrónico que se muestra aquí a continuación se envía a la dirección de correo electrónico del nuevo usuario para su verificación.
Toda la actividad de registro anterior registra efectivamente a un usuario en un sistema funcional completo de inicio de sesión de intercambio de token de correo electrónico/contraseña que admite los tres primeros métodos de inicio de sesión (nombre de usuario/contraseña, enlace mágico y contraseña de un solo uso) que se muestran en nuestro cuadro de diálogo inicial del Portal.
Pero el código se vuelve más interesante a partir de aquí a medida que continuamos generando un token de inicio de sesión de MFA basado en imágenes para el registro de nuestro usuario. Al hacer clic en el botón "Verificar mi correo electrónico" en el correo electrónico, el programa GateKeeper.php que se encuentra en la carpeta Storybook/Portal abrirá la siguiente pantalla del navegador que se muestra a continuación. La página web del programa GateKeeper primero informa al usuario que su correo electrónico se ha verificado con éxito y continúa solicitando al usuario que elija una imagen de avatar de "guardián" de una galería de imágenes.
Incluido en el repositorio de código en GitHub hay un programa de desarrollo de utilidad llamado dumpSessionZ.php (o dumpSession.php si no usa el administrador de base de datos de sesiones Zebra session2DB incluido en el repositorio) que permitirá la visualización periódica de PHP $_SESSION variables a medida que se ejecutan los programas. Estas siguientes imágenes son los resultados de la ejecución de dumpSession contra la página del programa GateKeeper.php como lo vemos arriba, y perfila la actividad del programa PHP en ejecución, permitiéndonos "seguir".
El aspecto principal de la función de GateKeeper consiste en manipular varias matrices de archivos de imágenes que luego usamos para completar la galería de selección en pantalla. La intención de estas maquinaciones es reorganizar el orden de visualización de las imágenes de la galería aleatoriamente en cada carga de página. Si observa el código GateKeeper.php , notará que hemos insertado una trampa de excepción en la sección superior del código que selecciona las imágenes para mostrar, de modo que podemos especificar la inclusión de una imagen de usuario en particular en la galería. Esto nos permite estar seguros de que esta imagen se puede seleccionar como el avatar del guardián del usuario de la excepción de captura. Esto tiene dos ramificaciones.
En primer lugar, me permite incluir específicamente mi propia foto policial personal en el tutorial de demostración ☺ . Sin embargo, en segundo lugar, proporciona un lugar conveniente para insertar una corrección que podría usarse para hacer que una imagen en particular esté disponible para cualquier usuario específico.
Sin embargo, continuemos y supongamos que nuestro usuario hizo clic en la imagen del avatar que se muestra seleccionada en la pantalla anterior de GateKeeper. Esto da como resultado la visualización de la primera página de información de ficha policial que se muestra a continuación. La imagen de esta página es una imagen JPEG cargada desde la carpeta Storybook/Portal/ckimages por el programa Storybook/Portal/mugshotChoice.php .
Esto también da como resultado agregar algunos valores más a la matriz de datos PHP $_SESSION que podemos examinar actualizando nuestra pantalla dumpSession . De especial interés es la información de la base de datos de usuarios, incluida la dirección de correo electrónico del usuario y el nombre y apellido, junto con el valor de los factores que se muestra a continuación.
Si hacemos clic en la imagen de Gatekeeper para continuar con nuestro registro de usuario, esta acción da como resultado que mugshotChoice.php emita una solicitud POST de formulario a nuestro servidor API de Node PGP . El terminal Node mostrará la siguiente pantalla a medida que genera y guarda un par de claves PGP para este usuario y luego espera la siguiente solicitud de API.
Cuando la API completa la generación de claves, las guarda en una base de datos y devuelve al usuario a la aplicación principal mediante un correo electrónico de aviso de finalización de la API de PGP. visualización de la página web que se muestra a continuación que incluye la dirección para cargar Storybook/Portal/showMugshotChoice.php . El código para el servicio Node API tal como está instalado se incluye en el repositorio de este artículo en la carpeta Authur/openPGP y hay más información sobre el propio código API en este artículo ( https://medium.com/@itzbobwright/some-openpgp- crypto-functions-on-a-node-api-server ) y su repositorio de GitHub asociado.
Esta configuración permite el uso de una API que está en un dominio separado de la aplicación de inicio de sesión y permite el uso del repositorio openPGPjs NodeJS que puede encontrar como una bifurcación en este repositorio de GitHub en https://github.com/Bob -Wright/openpgpjs .
Consideremos algunos aspectos de esta separación que podríamos aprovechar. Podríamos tener nuestra API de servidor de nodo PGP ejecutándose en el mismo servidor que nuestro portal de inicio de sesión. Otra consideración sería conectar el servidor del nodo PKC al servidor de la aplicación de inicio de sesión a través de una IP privada o un esquema de aislamiento similar. Se podría usar la dirección IP del servidor en lugar del sistema DNS de Internet.
Pero para continuar con la discusión del esquema actual, el usuario hará clic en la imagen como se indica para cargar showMugshotChoice.php con la siguiente página como resultado.
Si hacemos una actualización de dumpSession en esta página, podemos ver cuatro valores de datos más agregados a las variables de matriz PHP $_SESSION como se muestra a continuación. La matriz ahora incluye un valor para una clave pública de estilo PGP que se almacena con el valor de clave de matriz $_SESSION de [texto sin formato] junto con otros tres valores para las claves [coverImage] , [stegoImge] y [secretKey] . El valor [texto sin formato] , es decir, el BLOQUE DE CLAVE PÚBLICA PGP , se recupera de una base de datos clave donde fue escrito previamente por nuestra API Node PGP.
El programa showMugshotChoice.php ha utilizado estos valores para generar la imagen que se muestra en la pantalla de arriba y esta imagen es ahora una nueva imagen guardada en formato PNG que se ha codificado esteganográficamente para incrustar criptográficamente el valor PGP PUBLIC KEY BLOCK.
En este momento, hemos utilizado la parte de registro o inscripción de nuestro Portal de inicio de sesión para crear y guardar toda la información que usamos actualmente en nuestro Sistema de autenticación de usuario MFA basado en imágenes de Authur . Si nuestro usuario ahora hace clic en la imagen como se indica, volverá a una nueva página del portal de inicio de sesión con una nueva matriz $_SESSION borrada como se muestra en las dos pantallas a continuación y puede continuar con su inicio de sesión en Storybook Comic Book Builder.
Antes de hacer clic en nuestra segunda imagen de información de ficha policial y mientras nuestra matriz $_SESSION aún está cargada, podemos desviar nuestra atención para usar otro programa que también se incluye en la configuración de demostración. Si navegamos a la página Storybook/Portal/decodeStego.php , se nos presentará esta pantalla a continuación, que muestra una extracción de prueba de concepto del BLOQUE DE CLAVE PÚBLICA con codificación criptográfica e incrustado esteganográficamente para este usuario.
Como resumen, estas siguientes imágenes son las capturas completas de dumpSession para la página anterior.
Eso completa nuestro examen del código utilizado en el componente de inscripción o registro de nuestro sistema de autenticación de usuario MFA basado en imágenes de Authur . La siguiente y última sección de nuestro código que consideraremos es la función del componente de inicio de sesión en la que verificamos que nuestro usuario recién registrado acceda a nuestra aplicación Storybook alojada. Estén atentos a la reseña que, con suerte, llegará pronto.
Para la próxima iteración de nuestro Sistema de autenticación de usuarios, la intención es agregar dos instalaciones. La primera instalación sería incluir un método para usar mediante programación nuestra imagen esteganográfica generada para acuñar o crear una imagen NFT para usar como nuestra imagen de token MFA. Una consideración importante aquí es el costo y para la demostración, la acuñación no debe tener tarifa de gas. La segunda instalación permitiría a un usuario cargar su propia imagen de avatar de guardián proporcionada por, por ejemplo, una base de datos de empleados que luego podemos convertir a nuestro formato NFT esteganográfico.
Permítanme ofrecer algunos agradecimientos bien merecidos y PROPS a todos los codificadores benévolos cuyo trabajo contribuyó amablemente a este esfuerzo. ¡¡Finalmente gracias a Dios ya mi familia por el apoyo tan excelente!!
También publicado aquí.