Mi escuela quiere mantener en secreto los detalles de nuestro sistema de autenticación de puertas. ¿Es eso una buena idea?

La obscuridad no es una mala medida de seguridad. Confiar en la oscuridad, como su medida de seguridad única o más importante, es más o menos un pecado cardinal.

Principio de Kerckhoff es quizás el argumento más citado contra la implementación de la seguridad en la oscuridad. Sin embargo, si el sistema ya está correctamente protegido de acuerdo con ese principio, esto no es correcto.

El principio, parafraseado, dice "asuma que el enemigo sabe todo sobre el diseño de sus sistemas de seguridad". Esto no implica de ninguna manera "decirle al enemigo todo acerca de su sistema, porque ellos lo saben de todos modos".

Si el sistema ya está bien diseñado de acuerdo con el Principio de Kerckhoff, lo peor que se puede decir acerca de la aplicación de seguridad a través de la oscuridad es que agrega poco o ningún valor. Al mismo tiempo, para un sistema de este tipo, la protección de la confidencialidad de su diseño es igual o nula.

Mantener el diseño en secreto no hace que la puerta sea insegura per se ; sin embargo, creer que aumenta la seguridad es una ilusión peligrosa.

Si revelar los detalles del sistema de autenticación permitiría romperlo, entonces ese sistema es basura pura y debe ser descartado. Por lo tanto, si hizo su trabajo correctamente, entonces revelar los detalles debería ser inofensivo. Si no hizo su trabajo correctamente, despídase y contrate a alguien competente.

En general, los detalles del sistema de publicación promueven revisiones externas, que dan como resultado un ciclo de reparación, que en última instancia mejora la seguridad. En un contexto escolar, los detalles del sistema de publicación no dañan la seguridad, ya que las escuelas están llenas de estudiantes, y se sabe que los estudiantes son anarquistas entrometidos que se sentirán especialmente atraídos por la ingeniería inversa de cualquier cosa que se les mantenga en secreto. Es bien sabido que en la sala de computadoras de un estudiante, la mejor manera de mantener bajos los incidentes de seguridad es dar la contraseña de administrador / root a un par de estudiantes, cuando un estudiante quiere meterse en la seguridad de la computadora, dándole acceso completo elimina todos los incentivos para tratar de romper cosas, Y lo convierte en un auxiliar policial gratuito para monitorear a los otros estudiantes.

Además, detallar el funcionamiento interno de un sistema de seguridad podría ser un esfuerzo altamente pedagógico. He oído que en algunas escuelas practican la pedagogía, al menos ocasionalmente. Es posible que tu escuela quiera darle una oportunidad.

Ya has recibido varias respuestas excelentes, aunque las respuestas de @TomLeek e @ Iszi (ambas excelentes por cierto) parecen estar en contradicción directa.

Ambos tienen excelentes puntos: por un lado, mantener el secreto del diseño no hará que el sistema sea seguro, mientras que revisarlo públicamente le permitirá (posiblemente) encontrar ciertas vulnerabilidades que no había considerado; por otro lado, no hace daño mantener el diseño en secreto, siempre y cuando no sea un factor clave en la seguridad del diseño.

Ambos lados son absolutamente correctos, a veces .

Creo que sería justo decir que ambas partes en el argumento general estarían de acuerdo en que mantener el diseño en secreto no aumenta directamente la seguridad.
En el peor de los casos, simplemente oculta las debilidades de seguridad (lo que puede o no ser algo bueno, dependiendo de a quién consideres que está más oculto).
En el mejor de los casos (donde no hay vulnerabilidades triviales que serían expuestas al publicar el diseño), todavía no aumenta la seguridad, pero sí minimiza la superficie de ataque .

Minimizar la superficie de ataque (incluso sin la presencia de una vulnerabilidad) es definitivamente algo bueno; sin embargo, esto debe sopesarse e intercambiarse con los beneficios de la publicación (es decir, ser revisado por conjuntos de ojos adicionales), y la desventaja de mantenerlo en secreto, por ejemplo. la tentación de confiar en él como un control de seguridad (la seguridad siempre popular por la oscuridad), como una forma de teatro de seguridad.

También vale la pena señalar que, como se aludió a @Tikiman, el simple hecho de publicar el diseño no es suficiente para asegurar que se revise , especialmente por aquellos que son capaces de encontrar las vulnerabilidades y quienes también lo son. Dispuesto a revelarlos a usted. En muchos casos, un diseño publicado solo sería revisado por aquellos individuos malintencionados con intención ilícita, por lo que no lograría el beneficio esperado. Además, a menudo uno ni siquiera sabe si su diseño cae en el mejor o el peor caso mencionado anteriormente.

Por lo tanto, en resumen, como en muchas cosas en materia de seguridad, la respuesta directa sigue siendo: Depende .

Aquí hay que considerar un compromiso definitivo: si se tratara de un sistema criptográfico complejo, la respuesta sería clara; Si se tratara de un sistema empresarial típico de implementación pesada, una respuesta diferente sería clara.

Mi inclinación en este caso es como dijo @Tom, pero por las razones secundarias mencionadas, en parte la base de usuarios anárquicos, y principalmente el objetivo pedagógico.

Tenga en cuenta que estas no son realmente consideraciones de seguridad, al menos no directamente.

(Ah, y en cuanto al punto de @ Tikiman: la pedagogía involucrada aquí significa que realmente puede asegurarse de que el diseño sea revisado, al menos por toda la clase ;-))

¡Este artículo de Daniel Missler es genial!

Indica que

  

La seguridad por oscuridad es mala, pero la oscuridad cuando se agrega como una capa en   La parte superior de otros controles puede ser absolutamente legítima.

Al tener ese concepto, una pregunta mucho mejor sería

  

Es agregar oscuridad el mejor uso de mis recursos dados los controles I   tener en su lugar, o sería mejor añadir un diferente   ¿Control (no basado en la oscuridad)?

También podemos utilizar la anología de camuflaje como obscurity as another layer of security

  

Un ejemplo poderoso de esto es el camuflaje . Considera un tanque blindado   como el M-1. El tanque está equipado con algunos de los más avanzados.   armadura jamás utilizada , y se ha demostrado repetidamente que es eficaz en   batalla real del mundo real.

     

Entonces, dada esta armadura altamente efectiva, el peligro para el tanque sería   de alguna manera aumentar si se pintara del mismo color que su   ¿Alrededor? ¿O qué tal en el futuro cuando podamos hacer el tanque?   completamente invisible? ¿Hemos reducido la efectividad de la armadura?   No, no lo hicimos. Hacer algo más difícil de ver no lo hace más fácil   atacar si o cuando se descubre. Esta es una falacia que simplemente   debe terminar.

     

Cuando el objetivo es reducir la cantidad de ataques exitosos, comenzando   con una seguridad sólida y probada y añadiendo oscuridad a medida que la capa cede   Un beneficio global para la postura de seguridad. Camuflaje logra   esto en el campo de batalla, y PK / SPA logra esto cuando protege   Servicios endurecidos.

Énfasis mío.

El comentario de Iszi también es excelente, afirma que es mucho mejor si cambiamos la palabra adding a enforcing , por lo que en resumen se verá como este

Summary:

La seguridad por oscuridad es mala, pero la seguridad aplicada con oscuridad como una capa sobre otros controles puede ser absolutamente legítima. Suponiendo que estás a salvo en el campo de batalla porque crees que tu tanque está pintado con el mismo color que el entorno es simplemente una tontería . ¡Pero hacer que la defensa de tus tanques sea excelente y aplicar la pintura que te otorga la capacidad de camuflaje como otra capa de protección es excelente!

Si bien no responde realmente a su pregunta, esto podría ser un argumento para su escuela.

Consideraría que alguien que obtiene acceso a una clave / identidad autorizada es un riesgo real. La gente es descuidada, usa contraseñas malas y escribe secretos todo el tiempo. Una maestra en mi escuela, hace años, una vez dejó las llaves de toda la escuela en el baño de un estudiante.

Si quisiera entrar en esa sala, ni siquiera me molestaría en tratar de encontrar un agujero de seguridad en el software; Robaría la llave, intentaría manipular el bloqueo físico o algún otro método externo.

O, como dijo un amigo mío cuando el director le preguntó cómo iba a piratear el sistema escolar para destruir datos; "Yo usaría un bate de béisbol".

Tengo una larga explicación que puede parecer errante, así que daré una respuesta más breve y luego la justificaré. Respuesta corta, esto es seguridad a través de la oscuridad, pero esto probablemente no sea un problema debido a la cantidad de personas que entran en contacto con el sistema. Así que probablemente no vale la pena discutirlo.

Usted tiene razón en su afirmación de que mantener el diseño del sistema en secreto es la seguridad a través de la oscuridad (STO). La razón principal por la que la STO es una mala idea es que un sistema cuyo funcionamiento interno no se conoce inicialmente se puede realizar ingeniería inversa en todos los casos a través de una observación cuidadosa y la aplicación adecuada de la ingeniería social. Si usted es la única persona que entiende cómo funciona un sistema, usted es la única persona que puede verificar su integridad. Por lo tanto, si hay un defecto potencialmente pasable en su diseño y alguien invierte su diseño y lo descubre, puede explotarlo más fácilmente que si no hubiera mantenido sus diseños en secreto. También es más probable que puedan mantener en secreto su descubrimiento y su uso ilícito.

Esto se debe a que si hace que su diseño sea de conocimiento público, cuantas más personas lo examinen, cuantas más personas examinen un diseño, más probabilidades hay de que alguien descubra una falla existente y se lo cuente. Es posible que una falla de diseño ni siquiera esté en el concepto general, sino en la implementación específica, como la oportunidad de un desbordamiento de búfer en la implementación de un algoritmo que de otra manera sería seguro. El concepto principal del uso público de los primitivos criptográficos es que al hacer que todos conozcan sus algoritmos criptográficos primitivos, otros pueden revisarlo. Después de que un gran número de personas lo hayan hecho, puede estar seguro de que su diseño es seguro. La dificultad es que debido a que usted está haciendo un diseño para una escuela, solo un número muy pequeño de personas verá sus diseños, y muy pocos de ellos lo entenderán. Cuantas menos personas vean tus diseños, más probabilidades habrá de que todos los que descubran un defecto no denuncien el error.

A menos que tenga acceso a una gran comunidad de profesionales de la seguridad que estén dispuestos a revisar su diseño, dejar que ellos se salgan con la suya puede ser más o menos igual en términos de seguridad real.

Un objetivo obvio sería que los estudiantes no puedan hackear el sistema de autenticación de la puerta.

Si asumimos que el sistema de autenticación es ligeramente pero no muy difícil de piratear, y que hay estudiantes con algunas habilidades avanzadas de piratería, pero es muy posible que la dificultad adicional planteada al hacer que los detalles del sistema no estén disponibles. es suficiente para ponerlo fuera del alcance de ese grupo (los estudiantes).

Por otra parte, una vez que el sistema está tan seguro que el craqueo es mucho más difícil que encontrar o realizar ingeniería inversa del funcionamiento del sistema, mantener los detalles en secreto ya no es muy útil.

Si fuera responsable de la puerta, tendría el mismo requisito de confidencialidad. Si el mundo (y tu trabajo) fueran perfectos, la oscuridad de hecho será inútil.

Pero solo piensa en lo que realmente sucede en un mundo real. Supongo que hizo su trabajo lo mejor que pudo, utilizando algoritmos de vanguardia. Pero el diablo se oculta en detalles, y un detalle de implementación puede debilitar la seguridad. Le sucedió a la biblioteca SSL no hace mucho tiempo, incluso si los algos eran realmente seguros.

Lo que desea al revelar los detalles de su sistema de seguridad es que sus pares revisen su implementación y le adviertan sobre posibles fallas antes de que los atacantes las descubran y usen. Si conoce a expertos en sistemas de seguridad y les pide que revisen su trabajo, creo que se consideraría una buena práctica incluso en su escuela: en mi humilde opinión, debería al menos. ¡Pero si lo publicas, es más probable que tus primeros lectores sean aquellos contra quienes se construyó la seguridad de la puerta! Y ciertamente no desea que sean los primeros en revisar su trabajo en busca de posibles fallas.

TL / DR: Si construye un sistema de seguridad general, podría tener una gran audiencia y no lo usa inmediatamente en producción, debe publicarlo lo más amplio posible para obtener buenas críticas. Pero si crea una implementación dedicada que se utilizará de inmediato para seguridad real, solo revele detalles a expertos de confianza para evitar ayudar a los atacantes a encontrar posibles fallas.