¿Debe estar oculta la contraseña de un canal protegido por contraseña?

  

Personalmente, no veo una razón por la cual la contraseña debe estar oculta, porque al establecer la contraseña, queda absolutamente claro que otras personas necesitarán saberla.

Entonces, ¿por qué molestarse en almacenar la contraseña, simplemente deje que alguien entre? ;)

Si está almacenando un secreto, es porque este secreto identifica un subconjunto de sus usuarios totales. No todos tus usuarios potenciales lo saben. Ahora, probablemente le hayan dicho que las contraseñas deben almacenarse con hash y con sal. Esta es una contraseña con la que estás tratando. Te dejaré sacar la conclusión lógica.

Quizás el mismo grupo lo usa para acceder a un SharePoint que ocasionalmente contiene información confidencial. Tal vez lo usan para el calendario de su grupo, que revela cuándo su oficina está vacía o cuando viajan lejos de casa. Tal vez la persona que creó una cuenta estaba tan fuera de pista que usó una contraseña que de otro modo sería valiosa para sus activos personales. Tal vez simplemente no pueden lidiar con la cantidad de credenciales que deben manejar y eso solo explica la reutilización.

No sea la persona responsable de causar daño a otros por pura negligencia. Hash ellos (con un algoritmo de hashing de contraseña lento). Salgalos (con una sal única por contraseña).

Depende de su situación, es una buena práctica que las contraseñas contengan su base de datos comprometida o que la red de su cliente le permita al atacante obtener acceso a cualquier contraseña que lograra obtener.

Ventajas de hashear tu contraseña:

• El atacante tendrá mucho más que realizar para obtener acceso a grupos de chat privados, ya que tendrá que descifrar la contraseña. (Fuerza bruta, tablas de arco iris) o conjunto de hash que él / ella conoce.
• Si también está hash a través del cliente, un atacante que utilice la técnica MITM solo obtendrá su hash de su contraseña. Por lo tanto, si usa la misma contraseña en otros sitios, debería estar más seguro que el atacante que captura su contraseña de texto sin formato.

Desventajas de hash tu contraseña:

• No podrá mostrar la contraseña original sin tener ya la contraseña.

Entonces, imaginemos que encontraste mi contraseña con hash a través del ataque MITM: $ 2a $ 10 $ VcSYK / yD0T.vXencRFWv6O.8PZtsTMG7ZxZXNRSMXKu9.JTD5RNCS Intenta encontrar la contraseña? Quién sabe que puede ser la contraseña de mi cuenta de StackOverflow. ;)

Mi punto es que es mucho más seguro usar el hash, ya que el atacante tiene mucho más que hacer. Tendrá que utilizar la fuerza bruta o usar la tabla del arco iris para obtener el valor original antes de que se trillara.

Una contraseña compartida es un diseño deficiente para administrar el acceso a un canal de comunicación privado. Por ejemplo, no puede expulsar a un usuario sin cerrar el canal: no puede hacer que olviden la contraseña. No puede evitar que un usuario comparta la contraseña con otros usuarios (de manera voluntaria o involuntaria): si la contraseña de un usuario está expuesta, puede invalidarla, pero si la contraseña compartida está expuesta, es un inconveniente para todos los que usaron esa contraseña. / p>

Un diseño mejor separaría la autenticación de la autorización . Primero autentique al usuario, por ejemplo, pidiéndole una contraseña ("¿Afirma que es Bob? ¡Pruébelo!"). Una vez que un usuario haya sido autenticado, determine a qué canales tiene acceso el usuario al buscarlo en una base de datos ("Vamos a ver si Bob debería tener acceso al canal loco del bucle zurdo").

Esta separación de inquietudes tiene muchas ventajas, pero tiene la consecuencia de que puede o no importarle: la manera fácil de hacerlo depende de una autoridad central para determinar quién tiene acceso al canal. El enfoque de contraseña compartida elimina esta autoridad central, pero al costo de tener una política de control de acceso bastante inflexible (cualquier usuario puede permitir que cualquier otro usuario se una, y solo el consenso total puede mantener al usuario fuera).

Si el canal realmente tiene que estar protegido por contraseña, porque esa política de control de acceso impar es lo que realmente desea, entonces debe responder dos preguntas:

1. ¿Cómo se comunicará la contraseña a los nuevos participantes?
2. ¿Espera que los usuarios vuelvan a escribir la contraseña cada vez que se unan?

Si la respuesta a (1) es que alguien tiene que saber la contraseña para divulgarla, entonces alguien tiene que almacenar la contraseña en una forma recuperable, por lo que el hashing no está disponible para quien da la contraseña. Si la respuesta a (2) es que los usuarios almacenan la contraseña en algún administrador de contraseñas, el hecho de incluir las contraseñas en el servidor de autenticación solo proporciona una pequeña cantidad de protección, pero sigue siendo una buena idea.

Siguiente pregunta: ¿qué tan grande es el problema si la contraseña es recuperable en el servidor? El hash de contraseña solo aborda una amenaza específica: si el adversario obtiene acceso de solo lectura a la base de datos. Si esto le permite al adversario recuperar contraseñas, entonces:

1. Obtienen acceso al servicio.
2. Obtienen acceso a otros servicios donde el mismo usuario ha usado la misma contraseña.

Para una contraseña compartida, (2) no se aplica, solo (1). Así que es menos importante que con las contraseñas para las cuentas de usuario. Hay una ventaja de almacenar la contraseña en forma de hash, pero no una decisiva.

Para abreviar una larga historia, una contraseña compartida no es un buen modelo. Si está atascado con él, hay una buena posibilidad de que tenga que almacenar la contraseña en una forma recuperable de todos modos, y no es su mayor problema. Rompe la contraseña si puedes, pero si no puedes, entonces no te quedes dormido al respecto.

Tenga en cuenta que si los usuarios pueden crear su propio canal protegido, no se les debe permitir seleccionar la contraseña. En mi experiencia, estas contraseñas compartidas son invariablemente difíciles de escribir, pero fáciles de forzar las contraseñas, como CraZyStraWs!!!1 . Genere automáticamente una contraseña aleatoria sensata (como 10 letras minúsculas seleccionadas de manera aleatoria) y obligue a los usuarios a usar esa.

Pero, en realidad, no use una contraseña compartida. Utilice una base de datos de acceso de usuario / canal.

Tu lógica no es sólida.

"La contraseña no debe estar oculta porque muchas personas necesitarán la contraseña".

La segunda parte de tu declaración es verdadera y has decidido que eso dicta que la primera declaración debería ser verdadera. En realidad no están relacionados. ¿Las personas que necesitan la contraseña deben obtenerla de su servidor? Se siente como si debieran obtenerlo de otros usuarios.

Así es como lo abordaría:

"La contraseña debe estar oculta porque nunca habrá un requisito para que el servidor venda la contraseña a los usuarios".

o

"La contraseña no debe estar oculta porque habrá un requisito para que el servidor venda la contraseña a los usuarios y existen controles que impiden el acceso no autorizado a las contraseñas en la base de datos."