¿Es seguro usar la autenticación básica en una aplicación iOS?

  

¿Se guardarán el nombre de usuario y la contraseña en cualquier historial o registro?

Comúnmente, los encabezados de autorización no se registran pero, por supuesto, uno podría configurar la aplicación o el servidor para registrar estos datos. Por lo tanto, compruebe su configuración.

En cuanto al almacenamiento en el historial: en el caso de un navegador, dichas credenciales no se almacenarán en el historial, pero podrían almacenarse de manera similar a las cookies y enviarse automáticamente cuando visite el sitio. Sin embargo, dado que no está utilizando un navegador sino su propia aplicación, depende de usted cómo administrar esta información.

Debe usar un token temporal después del primer intercambio, para evitar transmitir la credencial real con cada solicitud. Por lo tanto, sus aplicaciones solo tienen que recordar el token temporal, no las credenciales completas.

Y sí, es mejor ponerlo en los encabezados que en la url:

• las urls pueden ser registradas por el cliente
• las direcciones URL son probablemente registradas por el servidor
• las URL pueden filtrarse ( enlace )

No estoy completamente seguro de si el OP pregunta directamente si el esquema es completamente seguro una vez que se usan los encabezados:

  

Mi pregunta es ... si me deshago de pasar el nombre de usuario y la contraseña como lo estoy haciendo actualmente y los codifico en base64 antes de enviarlos, inclúyalos en el encabezado como se muestra a continuación, ¿es seguro?

... o, si la pregunta solo se relaciona con el registro del lado del cliente, y no la seguridad general :

  

¿Se guardarán el nombre de usuario y la contraseña en cualquier historial o registro?

Sin embargo, asumiendo que la pregunta es de seguridad general, me gustaría señalar que aunque el OP está usando HTTPS, entiendo que transferir las credenciales de cada solicitud se considera malo hoy en día porque los ataques de repetición de MITM todavía son posibles (aunque se emplea HTTPS). Por lo tanto, incluso cuando se usa HTTPS, un esquema de token como JWT debe ser favorecido sobre el uso de la Autenticación básica cada vez que se solicite.

  

¿Esto es seguro?

No especialmente. La codificación Base64 se puede revertir fácilmente.

  

¿Se guardarán el nombre de usuario y la contraseña en cualquier historial o registro?

Tal vez, no es realmente posible decir de la información disponible. Por supuesto, es posible que los datos se registren en un ataque MitM.

Esto realmente se reduce a una cuestión de riesgo. Es una buena práctica, absolutamente no. ¿Sería adecuado para los registros financieros / de salud, ciertamente no. ¿Sería lo suficientemente bueno al probar un nuevo producto, casi seguro, especialmente si no está grabando datos en vivo y restablecerá la base de datos antes de la puesta en marcha?

Creo que su enfoque general es fundamentalmente defectuoso. Si bien puedo entender completamente de dónde viene su forma, su enfoque general es erróneo.

Uno de los grandes contribuyentes al bajo nivel de seguridad en muchas aplicaciones se debe a que deja la seguridad en una etapa posterior en lugar de construirla al principio. Con demasiada frecuencia, el enfoque es "permite que la aplicación funcione y nos ocuparemos de la seguridad una vez que tengamos la funcionalidad básica en funcionamiento.

El problema con este enfoque es que hacer que la funcionalidad básica funcione a menudo establecerá restricciones y guiará el diseño de tal manera que sus opciones en materia de seguridad se vuelvan limitadas.

Esto es completamente comprensible. Cuando te sientas a la derecha de la nueva aplicación asesina, quieres centrarte en las partes interesantes: la funcionalidad clave que deseas ver y el progreso real. A menudo, hay gerentes y tomadores de decisiones que aumentan la presión para producir algo que ver. Todo este material de seguridad es solo un andamio que se interpone en el camino, una especie de mal necesario.

Desafortunadamente, con demasiada frecuencia, esto resulta en una falta de énfasis en la seguridad. O bien el diseño hace que agregar la seguridad suficiente sea demasiado difícil u otras presiones, como los plazos de entrega, significa que se cortan las esquinas.

Comience con el modelo de seguridad. Haz que funcione y luego comienza con la funcionalidad de la aplicación. El resultado será un mejor diseño y algo que es más fácil de mantener. En este caso específico

• Sí, definitivamente deshacerse del enfoque de parámetros GET.
• Olvídate de la codificación base64. Realmente no le está comprando nada y es probable que cree una falsa sensación de seguridad.
• Busque formas de minimizar la necesidad de enviar la contraseña o incluso el nombre de usuario. Considere usar algún tipo de token de autenticación.
• Asegúrate de que tus tokens estén encriptados.

Hay muchas ventajas al usar un token de autenticación en lugar de solo un nombre de usuario y contraseña. Puede cifrar información adicional en el token, como el tiempo de caducidad. Incluso he visto tokens que incluyen detalles del cliente, como la versión del navegador y la información del sistema operativo, que se pueden utilizar como un tipo de huella digital.

La principal ventaja de usar un token es que solo pasa la cantidad de veces los nombres de usuario y las contraseñas. Cuanto menos necesite enviar esta información, mejor. Sin embargo, para usar los tokens de manera efectiva y segura, deben estar diseñados para su aplicación y no ser agregados posteriormente.

la otra ventaja de crear esto en tu aplicación desde el principio es que puedes probar más fácilmente los diferentes enfoques y bibliotecas que existen. Hay una serie de diferentes soluciones de autenticación y autorización basadas en token y necesita identificar cuál es la más adecuada para su arquitectura, idioma y plataforma. Haga esto desde el principio y el resto caerá en su lugar con mucha más facilidad que si lo intentara con una base de código existente.

  

¿Esto es seguro? ¿Se almacenarán el nombre de usuario y la contraseña en cualquier historial o registro?

Al menos mitigará el riesgo de GET, ya que normalmente no se capturan registros de encabezados en un proxy o un servidor web.

Pero es mejor utilizar HTTPS dentro de su aplicación ya que no tiene para comprar un certificado digital si está tratando con su propio servidor web. Puede utilizar la fijación de certificados y el certificado autofirmado será lo suficientemente seguro: enlace .