Me gusta el enfoque de no depender de mucho marco sabio, ¡pero una buena seguridad es difícil! Por el contrario, sugiere que los servicios de terceros remotos serían una opción. Si solo tiene uno, entonces está bien, aunque todavía está aprendiendo un poco, de lo contrario, tenga en cuenta la UX múltiple, ya que el usuario no siempre puede recordar qué servicio utilizó, lo que significa que puede terminar consolidando los registros de usuario.
Estoy seguro de que hay libs y frameworks disponibles que facilitan la autenticación simple del lado del servidor. Actualmente, el mejor método para almacenar contraseñas es bcrypt, así que solo busque en las bibliotecas para esto y excluya todo lo demás (literalmente, por ejemplo, MD5 puede clasificarse como ‘simple’ pero también es demasiado fácil de explotar de múltiples maneras, la más simple son las tablas de arco iris).
De lo contrario, cree su propio ‘marco’, que en mi humilde opinión es mejor en comparación con el desorden UX de múltiples métodos de autenticación (sin mencionar libs, puntos finales y consolidación de registros). Una vez que se familiarice con lo básico (y solo lo básico) no es tan difícil de manejar y es una gran experiencia de aprendizaje, a menos que necesite comenzar a incluir permisos facetados (usuario normal versus administrador), múltiples dispositivos, mucho tráfico, DDoS evitación, y cosas así.
- ¿Cuál es la forma más fácil de cargar el sitio web muy rápido?
- ¿Qué pasos debo seguir para construir mi propio sitio web y alojarlo?
- ¿Cómo es que algunos sitios web dicen que necesitan que los incluya en la lista blanca en mi bloqueador de anuncios, pero otros sitios web tienen muchos anuncios?
- ¿Cuáles son algunas alternativas similares a Gigster (http://gigster.com)?
- Cómo vender mi sitio web en Flippa
- Cree un formulario de registro y almacene la contraseña como un hash de bcrypt en su registro de usuario de base de datos. (No guarde nunca su contraseña de texto sin formato en ningún otro lugar. Idealmente prohíba las contraseñas más comunes. No aplique ninguna otra regla tonta). Guarde el correo electrónico también y úselo como ID de inicio de sesión, en lugar de un nombre de usuario que a menudo es diferente de un servicio a otro y, por lo tanto, difícil de recordar, además se puede cambiar.
- Cree un formulario de inicio de sesión que envíe el correo electrónico y la contraseña (preferiblemente a través de SSL), obtenga el hash existente de la base de datos para ese correo electrónico y llame a la biblioteca bcrypt con él y la contraseña de texto sin formato del formulario (el comportamiento puede variar entre libs). Si no es válido, devuelve un error que indica si el correo electrónico o la contraseña no son válidos (a menos que desee molestar a sus usuarios).
- Si es válido, genere y establezca un token de sesión en su base de datos (asociando el registro de usuario) y como una cookie en la respuesta al navegador. Utilice una biblioteca G / UUID para generar la cadena de token aleatoria e idealmente almacene una marca de tiempo con el token de sesión. (Vale la pena establecer las banderas seguras y solo http para la cookie que ayudan a proteger contra XSS y ataques de hombre en el medio).
- Para todas las páginas protegidas / autenticadas, si la cookie de sesión está presente en la solicitud, verifique su validez con cada solicitud (y obtenga la identificación de usuario / campos / registro correspondiente …), de lo contrario, muestre una página de acceso denegado / de inicio de sesión. Por lo general, actualizaría la marca de tiempo en la base de datos para el token de sesión correspondiente con cada solicitud válida, y ocasionalmente caducaría las antiguas (por ejemplo,> 12 meses).
- Como no puede enviar recordatorios de contraseña (¡gracias a Dios!), Debe tener una función de reinicio. Cree un formulario que solicite solo el correo electrónico, compárelo con su base de datos y, si es válido, genere un nuevo token G / UUID para almacenar en la tabla de sesiones con la marca de tiempo nuevamente. Enviar un correo electrónico que contenga un enlace a / verificar? Token (o somesuch). Ahora cree la página de verificación que acepta el parámetro de consulta con el token, compárelo con el DB y, si es válido (y no demasiado antiguo), configure una cookie con el mismo token. Muestre un formulario solicitando una nueva contraseña y, al enviarla (tal vez a una nueva página), invoque las funciones de autenticación desde el paso 4 para que sepa qué registro almacenar el hash bcrypt actualizado.
Tada!
Por cierto, si desea verificar los correos electrónicos al registrarse, simplemente genere el token del paso 5 y envíe el correo electrónico al registrarse también. Realmente necesitará purgar (o enviar correos electrónicos de recordatorio) a usuarios no verificados, así que agregue una columna / campo ‘verificar’ adicional al registro de usuarios, luego guarde una marca de tiempo cuando genere el token y bórrelo una vez verificado. Podrá encontrar usuarios no verificados simplemente haciendo coincidir un valor no vacío en esa columna.
Con respecto a la respuesta de que una tabla de ‘usuarios’ y una contraseña salada son malas, cualquier intento de hacerlo usted mismo obviamente lo es (como se mencionó MD5), pero está bien usar un hash bcrypt correctamente salado. Para empezar, al usar otros servicios, no estás aprendiendo nada sobre el tema (incluso en el nivel más ligero). Realmente todo depende del caso de uso y las preocupaciones. La centralización (de los servicios) es excelente para la mitigación del abuso (por ejemplo, captchas ‘invisibles’, aprendizaje automático, filtrado DDoS), y de lo contrario (filosóficamente: la centralización compleja conduce a eventos de cisne negro, no una red resistente de pequeños autosuficientes interconectados e independientes sistemas como se concibió Internet). La relación riesgo-recompensa se pondera hacia un servicio centralizado solo con una alta probabilidad de abuso. De lo contrario, lo que describo anteriormente no es diferente de cualquier servicio de este tipo cuando se debe pasar un token desde y hacia él.
