Fellow programmer usó las peores prácticas de programación

La seguridad a través de la ofuscación nunca es una buena seguridad. Debe haber mejores formas de proteger su propiedad intelectual. Y eso es lo que usted y su colega deben plantear como una preocupación conjunta con su gerente. Si la gerencia decide que no quieren gastar el tiempo o el dinero en mejorar la seguridad, ambos tendrán que vivir con esa decisión (no es su producto, es el producto de la compañía) y es mejor no gastar (¿desperdicio?) Más tiempo sobre el tema.

Original: ¿Qué dice tu jefe? Descúbrelo: hazlo.

Me pidieron que elaborara lo anterior:

En primer lugar, creo que tienes más de un dilema:

• ¿Debería "arreglar" el código de otra persona?
• ¿Es la implementación (en este caso A) de las otras personas lo suficientemente mala como para ser reemplazada por otra cosa?
• ¿Un ofuscador (de aquí en adelante B) será mejor para esta "incorporación de licencias en nuestra aplicación"?

En primer lugar, visto desde un caso de negocios, el problema ES se resolvió. A está en su lugar y es, lo más probable, una solución "suficientemente buena" para el problema. Su empresa puede estar contenta con eso, básicamente, lo suficientemente protegido como para que sea necesario un esfuerzo deliberado para romperlo.

Esto significa que incluso si no te gusta (y, créeme, verás mucho peor a lo largo de tu carrera ) hace lo que es necesario. Por lo tanto, a medida que se resuelva el problema, no debe "hacerlo", sino convencer a la persona a cargo de asignar su trabajo que el precio de largo plazo de esta implementación será lo suficientemente alto como para justificar un rollback y elegir un ofuscador de stock. Esto requerirá un poco de preparación por parte de usted, y también tenga en cuenta que los ofuscadores también tienen inconvenientes que usted debe saber (otras respuestas cubren esto también). P.ej. los rastros de pila no se pueden utilizar inmediatamente, etc. Todo depende de cuán importante es evitar la piratería. Tenga en cuenta que los más difíciles de romper son los que requieren el uso de dongles de hardware y probablemente sean más caros de lo que les gustaría a sus clientes.

Por lo tanto, esta decisión no es suya, ya que su empresa necesita utilizar recursos adicionales para ir a B. Por lo tanto, debe presentar sus inquietudes a la persona responsable, explicar esto y cualquier otro a largo plazo respete y actúe en consecuencia de una manera profesional. Tenga en cuenta que es muy probable que el autor original tenga que mantenerlo de todos modos cuando lo escribió y si se va o no quiere hacerlo más, entonces puede volver a hablar del tema.

En otras palabras: ¿Qué dice tu jefe? Descúbrelo: hazlo.

Tenga en cuenta también que esto habría sido diferente si hubiera planteado el problema anteriormente, de modo que el dinero gastado por el tiempo empleado en la implementación de A fue menor. En otras palabras, cuando la elección entre A y B debía realizarse.

Finalmente, me gustaría comentar su pregunta acerca de "solo corregir el código de otras personas". Esta no es una pequeña solución al código existente (lo cual me parece correcto y alentador, especialmente con las pruebas implementadas). Es un retroceso y una reimplementación disruptivos, e incluso en equipos con propiedad de código común, esto no sería algo aceptable, al menos para mí, sin aprobación previa.

Espero que esto aclare mi punto de vista.

  

¿Busco una biblioteca de ofuscador en   Java y arreglar su antiguo código (que podría   ser un poco susceptible acerca de la remodelación   su código), o lo dejo así, como   tanto como eso me molesta hasta el final?

No , retroceder detrás de alguien y modificar el código del que son responsables sería una ofensa peor que escribir el código cuestionable para comenzar.

Lo mencionó con el programador, su próximo paso es mantener su nariz fuera o hablar con la gerencia y luego mantener su nariz fuera.

¿Hubo una revisión oficial del código de algún tipo, o fue la confrontación con la que tuvo una "revisión del código" no oficial? Yo diría que, dado que este es un tema delicado e importante, como la seguridad y las licencias, es necesario plantearlo en la cadena. Has hecho la primera parte: confrontar al programador. Sin embargo, ahora que no está escuchando, puedes / deberías retomarlo. Si no lo hace, puede ser parte del problema.

Le diría que lo vas a hacer, esto PUEDE cambiar de opinión. Si no es así, escriba a su jefe un correo electrónico políticamente correcto, aunque preciso y conciso sobre la situación, y comuníquese con el programador. En el correo electrónico, solicite una reunión entre los tres y / o cualquier otra parte participante.

Siempre enfrente estas cosas, pero de una manera política y amistosa.

Si puede encontrar un ofuscador que pueda ofuscar la firma de clases (nombres de métodos, etc.), proponga comprarlo y usarlo.

Hasta entonces, es posible que tengas que vivir con eso. Admito que he hecho algo similar en un proyecto reciente de Grails: las comprobaciones de licencia están integradas deliberadamente en el método de inicio de sesión ya de gran tamaño, por lo que sería bastante difícil reemplazar el método para omitir la comprobación.

¿Puede demostrar que un hack es factible, o es solo un escenario hipotético que le preocupa? ¿Puede dar una demostración en vivo de este trabajo? Él debería intentarlo. Seriamente. Si funciona, debe presentarse a la gerencia y luego sugerir obtener un ofuscador.

Si un ofuscador no es lo suficientemente seguro, ¿ha buscado otras formas de asegurar el JAR, tal vez algo como cifrarlo o compilarlo en un código nativo?

RE: reelaborando su código: ¿Es solo una cuestión de cambiar el nombre? Muchos IDE tienen herramientas de refactorización que pueden hacer esto con bastante facilidad.

Independientemente de lo valiosa que sea su IP, lo inteligente no es destruir su código con la esperanza de confundir a los piratas informáticos. Aparte del hecho de que va a ser una pesadilla mantener el futuro, no soluciona ningún problema. Simplemente lo hace más difícil pero no imposible. Entonces no es realmente una solución y los efectos secundarios son malos. Es como tomar medicamentos que no funcionan y tienen efectos secundarios negativos.

Su problema es cómo asegurar su IP. Encuentre una solución para eso: ofuscadores, servidor de licencias, etc.

Me encontré con un problema similar cuando otro desarrollador llamó a nuestras rutinas de cifrado / descifrado str__copy y str__delete (note el segundo guión bajo). Era escaso y podría haberse hecho mejor, así que esperamos hasta que hubo una historia en la que era necesario actualizar la licencia. La administración no tuvo ningún problema con las pocas horas adicionales porque lo describimos como "limpiar así que la próxima vez que obtengamos las licencias, tomará menos tiempo y será más seguro". Problema resuelto, no hay sentimientos heridos.

Mi primer pensamiento fue el mantenimiento de ese código. Si el código ya está ofuscado y continúa, buena suerte intentando controlarlo. Entonces serás el hacker que intenta descifrar el código.

En cambio, recomendaría limpiar el código y usar un ofuscador hacer todo el trabajo duro. A largo plazo, tendrá un código muy manejable y dejará toda la loca complejidad para quien quiera hackear su licencia.

Recuerda que ningún ofuscador es perfecto, y un hacker muy determinado puede aplicar ingeniería inversa a cualquier cosa, pero al menos solo será él. Además, los obfuscaters añaden mucha más complejidad de la que probablemente pueda tener uno.

Estoy totalmente de acuerdo con las respuestas de que debes preguntarle a tu jefe sobre el problema y hacer lo que dice.

Sin embargo, un apéndice muy importante para estas respuestas es que debe documentar sus inquietudes sobre la seguridad y la capacidad de mantenimiento. Ya sea que cambie o no el código, es importante que las personas sepan de qué se trata y por qué. Esto es importante tanto de manera proactiva (su jefe no puede tomar una decisión que ni siquiera sabe que se debe tomar) y de manera defensiva (si / cuando un pirata informático hace un hueco en el sistema de licencias mal asegurado, no pueden culparlo por su error.)

"No seas el profesional más superior para saber de un problema".

En otras palabras, dile a tu jefe y vete de allí. Si te quedas en silencio y eres la parte superior del polo totum en ese secreto, cuando llegue el momento, serás responsable. Dígale a su jefe de paso y deje que él decida la manera de abordarlo. De esa manera usted se libera de la carga de la elección.

No se lo diga simplemente a su jefe, ya que muchos gerentes quizás no sean tan técnicos, sino que hacen lo que siempre hacemos: plantear el problema y las posibles soluciones con las ventajas / desventajas de cada una de esas soluciones. Entonces déjalos que decidan y que eso pase. ¡Es por eso que los gerentes / líderes ganan mucho dinero!

La verdad es que dado el tiempo y los recursos suficientes, cualquier cosa puede ser resquebrajada. Es una función simple de cuán popular es tu aplicación. Cuanto más popular es entre los piratas informáticos más hábiles que atrae y más tiempo se dedica a romperlo. La ofuscación de código proporciona precisamente eso: un medio para aumentar el tiempo requerido para romperlo, similar a la criptografía. Por lo tanto, si su código está ofuscado, se requiere que el atacante sea hábil y le dedique tiempo, de lo contrario se desesperará y se rendirá. Tienes que preguntarte si tu aplicación merece la pena en ambos extremos.

En realidad, es sorprendente lo difícil que puede llegar a descifrar el código ofuscado. Puede convertir fácilmente un programa simple de 10 líneas C en un conjunto de 100 líneas uno a través de la ofuscación. Si intenta depurarlo, saltará sin sentido en el código y puede ser realmente frustrante pasar a través de él. Eventualmente se romperá, pero se volverá realmente difícil y, como no hay nada realmente imposible, ese es el punto. La ofuscación de código reduce la cantidad de personas que pueden romperla.

Claro que hay mejores formas, como tratar de confundir al depurador, no al cracker, pero es barato y eficiente. Sin embargo, nombrar cosas torpemente no es suficiente. Tiene que cambiar las funciones de llamada de flujo de control que realmente no hacen nada por su código general, pero aumentan su tamaño y complejidad: llame a funciones ficticias cuyo valor de retorno no se usa en ninguna parte, desde funciones internas que realmente hacen algo. Ya puedes ver cómo esto puede ser realmente confuso.

Tienes algo que el atacante no tiene. El código fuente original. Encuentra una manera de organizarlo mejor para ti mismo.