sábado, 28 de noviembre de 2020

Modelos de trabajo para un desarrollador de software

Este articulo trata sobre las distintas formas y modelos de trabajo que como desarrolladores de software podemos desempeñar. Está escrito desde un punto de vista personal, repasando y exponiendo modelos de trabajo en los que de una forma u otra me he visto involucrado. Hay que considerar que dependiendo de cada país estos modelos pudieran cambiar e incluso ser más laxos o rígidos que otros en el cumplimiento de normas y leyes.


Existen formas explicar que es el trabajo, podemos considerar que es la labor y tareas que realizamos con la intención de recibir una remuneración económica.

Existe la falsa creencia que debemos ganar de forma proporcional por los conocimientos que tenemos, así que si nos hemos esforzado mucho y hemos estudiado deberíamos ganar mucho dinero, y si bien eso suena lógico y hasta justo, no es cómo funciona el mercado laboral. Los conocimientos y los estudios que tengamos, son solo una herramienta que vamos a usar en nuestra profesión, pero lo cierto es que en el mercado se nos pagara por lo que “hagamos”, no porque lo “sabemos”. Se cumplirían varias reglas:

  • Si existe mucha gente que sepa hacer lo mismo que nosotros (independientemente si para saber hacer eso mismo hemos “estudiado” mucho), cobraremos poco.

  • Si existe poca gente que sepa pueda lo mismo que nosotros, cobraremos mucho.

  • Si existe poco gente que pueda hacer lo mismo que nosotros, y lo que podemos hacer no es de interés para otras personas, puede que tengamos un hobby interesante.

Lo anterior es una simplificación de la ley de la oferta y de la demanda, aplicada a nuestra profesión.

Pero al margen de esa regla tenemos varios problemas adicionales que influyen con respecto a los sueldos que cobramos en nuestra profesión:

  • Nuestro trabajo llevaba décadas en alza, es decir la demanda de informáticos siempre ha crecido, particularmente esta creció de forma más rápida en los 90 y a principio de los 2000, donde además hubo una crisis llamada burbuja puntocom (además de otras crisis inmobiliarias debido a especuladores que puso varias veces en jaque a la economía mundial). Todo esto hizo que en la actualidad haya muchos informáticos y desarrolladores de software.

  • A pensar del anterior, los sistemas que desarrollamos no son siempre valorados como se debiera, debido a varios motivos; uno de ellos es que parece que hay una reticencia a que un usuario comprenda exactamente qué es lo que hacemos. Muchas profesiones con las que interactuamos como adultos se comprende “intuitivamente” (aun de forma superficial), comprendemos que hace que hacer un contable, un médico o un abogado, pero a frecuentemente (para una persona que no se dedica a los sistemas informativos) comprender que hacemos realmente los desarrolladores de software. Por otro lado la creación de sistemas generalmente crea un valor indirecto, es decir se crea un sistema para que sostenga un negocio, el cual es que el genera el valor directo (el dinero en sí). Por eso es difícil relacionar el costo de un sistema, con los beneficios económicos que produce.

  • Por otro lado la programadores somos personas realmente muy entusiastas con nuestra profesiones. Disfrutamos programar, lo cual es bueno en un sentido, pero malo en otro, ya que no alcanzan a valorar por si mismos el costo de su trabajo, ya que este suele ser gratificante.

  • Por último, y de forma más trágica, parece que nuestra profesión es la única en la que experiencia y madurez no significan mayores posibilidades de conseguir un trabajo. Nuestro trabajo, esta asociado con el cambio, la evolución, y de cierta forma con la juventud. Muchas empresas descartan contratar a gente a partir de cierta edad. Esto puede ser por varios motivos, pero el exceso de informativo graduados, la renovación tecnología constantes, y que en general es más barato contratar a una persona sin experiencia excesiva, hacen que las contrataciones sean muy desfavorables para la gente madura, con ya amplia trayectoria en el mercado laboral.

Hay que tener en cuenta los dos escenarios (la ley de la oferta y la demanda y las particularidades de nuestra profesión), para conseguir un salario digno y justo, y que podamos garantizarnos un ingreso fijo y constante en nuestro futuro.

Consultorías de software


Las consultorías son empresas expertas en el desarrollo de software que ofrecen su accesoria a otras empresas (de otros rublos), para la implementación adecuada de sistemas en sus negocios.

Esa “asesoría” puede tener muchas facetas, desde lo que es realmente una “asesoría”, incluyendo la venta y personalización de sistemas “prefabricados”, que se adapten a las necesidades del cliente hasta la creación de sistemas a medidas.

También es posible que el modelo de consultaría se acabe pareciendo mas a un modelo de “outsourcing”.

Los empleados trabajan para la consultaría y no para el cliente, toman los requisitos, los analizan y se presenta una proyecto que acaba implementando.

Una de las ventajas de la consultoría, es que son proyectos (en principio limitados), con un principio y un fin, y generalmente tiene cierta independencia en cuanto al desarrollo de este (siempre que cumpla con lo estipulado en plazos y recursos). Se puede decir que los codificadores cambiar de proyecto y el trabajo no se vuelve rutinario, hace que estén siempre estén “despiertos”, y buscando formas interesantes de resolver los problemas.

Otra de las ventajas es que al ser la consultoría un negocio dedicado a la creación de sistemas, los jefes y empleados, hablan un lenguaje semejante y que ambos entienden, lo que suele ser un alivio en muchas formas.

En cuanto al sueldo y el tipo de contrato, no suele hacer restricciones en este aspecto, es decir podría darse de cualquier forma, desde empleados fijos a empleados temporales (por proyecto), pero si suele haber un límite en lo que respecta al sueldo de los programadores (para que los productos que vendan suelan ser rentables).

Outsourcing o subcontratación de recursos humanos



La subcontratación, es el proceso en él que una empresa delega la resolución de un problema o una necesidad a una segunda empresa. Digamos que le “comprar” el trabajo.

La subcontratación tiene muchas facetas, y suele cambiar según la legislación del país, llegando a ser en algunos casos muy controversial.

Una empresa requiere un software, o alguna otra necesidad relacionada con el desarrollo de software, pero no quiere contratar nuevos recursos (con recursos nos referimos a específicamente a codificadores), porque eso requiere adquirir una seria de responsabilidades hacia ellos, como realizar un contrato temporal (para dar paso según la legislación a uno definitivo), a pagar vacaciones, enfermedades, impuestos y prestación social de diversa forma.

Lo anterior hace que no resulte atractivo a la empresa contratar recursos, ahí es donde entra el outsourcing, que contrata a la gente, y la pone a trabajar para la empresa, pero absorbiendo todas las responsabilidades con respeto al empleado (que formalmente pertenece al outsourcing).

Aquí es donde reside uno de los problemas principales en el outsourcing, y es que tiene que compensar para ambas partes, es decir la empresa subcontrata los recursos, porque el coste que le supone es menor que la contratación directa, el outsourcing ofrece sus servicio y asume la responsabilidad con los empleados, porque también le compensa económicamente, ¿Cómo es posible que compense a los dos, cuando en ambos lados, hay un costo económico?, impactando en el salario del programador. El outsourcing cobra a la empresa un costo que es atractivo para ambas partes, y de ese costo debe sacar su ganancia y pagar al codificador.

El outsourcing suele ser atractivo para recién egresados, o personas que están buscando su primer trabajo, ya que las empresas de esta índole suelen siempre buscar recursos para ofrecer a las empresas (y no son muy exigentes en cuanto a los requisitos o la experiencia) y los nuevos ingenieros buscan una oportunidad para obtener experiencia en el mercado laboral y comenzar una carrera.

Antes aceptar un trabajo en una empresa outsourcing revisa bien si te conviene a corto, mediano y largo plazo, y haz una estrategia que sea atractiva a tus intereses.

Se puede ubicar el tema de outsourcing en dos ramas principalmente.

Outsourcing para proyectos concretos


La empresa tiene la necesidad de desarrollar un proyecto de software muy concreto, con lo que contacta una empresa de outsourcing (que en este escenario trabaja más como una consultoría), y pone a disposición de su cliente los recursos necesarios para poder realizar su sistema.

El cliente puede intervenir en el desarrollo en menor o mayor medida. El outsourcing puede usar empleados fijos para que gestionen el proyecto (normalmente son los mas veteranos), y contratar otros exclusivamente para el proyecto.

En estos momentos y debido a que es un proyecto cerrado, generalmente tiene un cotos fijo, y en base de ese costo puede permitirse pagar más a las personas que contrata temporalmente pero es posible que su contrato finalice con la finalización del proyecto.

Outsourcing de recursos humanos


Aquí es cuando la empresa no necesita un desarrollo de software en particular, ni la asesoría en cuanto a tecnologías y sistemas. Lo que necesita la empresa son programadores que saque el trabajo según su control y especificaciones.

Básicamente son empleados mas, que trabajaba con la empresa, generalmente in situ, para sacar sus requerimos en la forma que esta lo necesite, pero siendo su empleador el outsourcing, la cual como comentamos tiene todas las obligaciones.

En este caso el sueldo del programador tienen que a ser menor, debido a que hay un intermediario entre el que pone el dinero (la empresa) y la que lo gestiona (el outsourcing).

El empleo puede ser temporal debido a que la empresa podría no requerir a los recursos en cualquier tiempo, aunque la verdad es que no suele ser así. Las necesidades de sistemas de las empresas no van a disminuir, sino mas bien a aumentar, con lo que el trabajo se acaba convirtiendo en una suerte de fijo, en el que el programador esta asignado a la empresa sin fecha de finalización. Es fijo en la práctica, pero no de forma contractual, con lo hay que considerar las posibilidades que esto lleva, una de ella es que la empresa decida cambiar de proveedor de outsourcing (porque le convenga mas, o sea más barata), en dicho caso el puesto sigue existiendo, pero es puede que se reemplace al programador por otro de la nueva empresa.

Otros de los problemas es la faltan de identificación, y la sensación de no pertenencia del programador con respecto a la empresa y viceversa. En muchos casos la empresa de outsourcing se dedica a encontrar recursos para otras empresas, y una vez que los tiene localizados, los manda a trabajar directamente en sus asignaciones con el cliente, aquí se da un problema en el que el programador no siente pertenecer a la empresa del cliente (donde realmente trabaja), ni a la empresa de outsourcing donde apenas pasa tiempo (y muchas veces no es conocido).

Empleado de una empresa cuyo giro no sean los sistemas



Hay que considerar que todas las empresas tienen necesidades en cuanto a software, pueden comprar software o paquetes pre construidos, pero llegara un momento en el que si empresa quiere impactar en el mercado, necesitara software personalizado a sus necesidades específicas.

Generalmente cuando la empresa llega a la conclusión que necesita un equipo de desarrollo in situ, ha pasado ya por varias fases:
  • Comprar software establecido en el mercado, que se acerque a las necesidades de su negocio.

  • De alguna manera contratar o pagar a un tercero para que gestione o personalice el software anterior, para que se ajuste a sus necesidades reales.

  • Darse cuenta que requieren un sistema más personalizado. Necesitamos que el sistema se adapte a su negocio, y no que el negocio se adapte a los que pueda hacer el sistema.

  • Contratar a alguna consultoría para que cree software específico para su negocio (cuyo propietario real es la empresa).

Cuando la empresa se da cuenta que requiere algo más cercano a sus necesidades y que le preste atención en el momento que lo necesitan, se plantea tener un equipo propio de desarrollo.

En proceso de tener un equipo propio de desarrollo también pasa por varias fases:

  • Creación de un equipo de soporte de infraestructura (tal como redes, impresoras, etc.).

  • El equipo de infraestructura da soporte al software y sistemas adquiridos

  • Se crea un subequipo de desarrollo de software, pero la mismas personas que dan soporte a la infraestructura, es la genera el software, es decir los roles están “mezclados” y son intercambiables.

  • Se crea una división real entre el equipo de soporte y el de desarrollo de software.

  • El equipo de desarrollo de software se organiza en una estructura que contenga los roles clásicos tales como líderes de proyecto, codificadores, analistas, testers…

Hay que ser consciente que no todas las empresas llevan a la última fase (o alguna de las anteriores), los dueños de la empresa no quieren obtener un equipo de desarrollo maduro, lo que quieren es vender su producto. También es cierto que los responsables del negocio no son expertos en sistemas, con lo que a veces es difícil convencerlos de las ventajas de tener un nivel de madurez en el equipo de desarrollo.

Debido a que la mejora en procesos, metodologías y tecnologías no tiene una ganancia directa en la empresa, los propietarios del negocio, no suele querer hacer cambios y mejoras (que serian evidentes para una empresa tecnológica), y podemos caer en una obsolescencia tecnología que estanque el negocio.

Es necesario saber “vender”, la ganancia de la evolución tecnológica continua en la empresa, y tener estrategias para hacer que la empresa (que insisto no está interesada en cambios tecnológicos), los pueda adquirir de la mejor manera y de la forma más sana, de no ser así, las tensiones entre los equipos de desarrollo (que conocen las necesidades de los sistemas) y las de los dueños o trabajadores (que conocen las necesidades de negocio), irán en aumento, haciendo difícil que ambas partes puedan cumplir con sus responsabilidades.

Otro problema es que el propietario de la empresa paga sueldos (nominas), y no paga directamente por software, por que se corre el riesgo que no valore correctamente lo que cuesta hacer software, y se subestime su precio real.

Freelance o autónomo


Es el trabajador que se establece por su cuenta, el vende su trabajo directamente a un cliente, y recibe su cobro.

Las ventajas de esta forma de trabajo son evidentes, libertad en cuento sus decisiones y gestión de su tiempo y recursos, con el añadido de que cualquier esfuerzo adicional que se haga para tu trabajo, es realmente para él.

  • Las desventajas son muy variadas:

  • El autónomo tiene que localizar a su cliente, a la vez que resuelve las necesidades de los clientes actuales.

  • El autónomo tiene que enfrentarse a circunstancias que no tienen que ver directamente con su trabajo, como son responsabilidades financieras y legales, que podrían no ser su fuerte, y a veces no tener tiempo para atenderlas.

  • La más evidente, su ingreso económico depende de su trabajo, si se enferma, o no consigue clientes, no recibirá ingresos, lo cual puede colocarle en una situación dedicada.

Es posible (y muy probable) que el autónomo compagine su trabajo como independiente, con otro trabajo como empleado de algún tipo, de forma que tenga un ingreso fijo, mientras que intenta emprender proyectos propios. Esta es la forma más segura de poder comenzar pero requiere muchas disciplinas, es difícil “quedar bien” con dos jefes (aunque uno de ellos seas tú mismo).

Debido a las complejidades anteriores, varios autónomos se suelen asociar para poder llevar acabo todas las tareas de forma más sencilla, puede que uno se encargue de los asuntos del negocio y otro de los asuntos tecnológico, o dividirse el trabajo entre todos. Esta quizás es la mejor forma, que permite equilibrar las funciones y responsabilidades de cada uno y demás tener el apoyo de un compañero. Por otro lado hay que tener en cuenta que las circunstancia pueden volverse tensas, y generar conflictos facialmente en este tipo de equipos, por eso hay que buscar hacer proyectos con compañeros profesionales y responsable y comportarse así al mismo tiempo. Sin duda habrá contratiempos, pero hay que saber lidiar con ellos, y poder sacar los proyectos adelante.

Empresa propia



Es cuando el desarrollador de software tiene una estructura formal de negocio, con un nombre comercial y empleados que depende de él.

El empresario adquiere unas responsabilidades superiores a las que ha tenido hasta ahora, por que no solo tiene compromisos con sus clientes, sino que además tiene compromisos con sus empleados.

Los productos que pueden vender a un cliente son varios, desde un paquete software prefabricado, a la personalización de alguno, software a la media, o entrar en un esquema de outsourcing donde rente recursos.

Hay que considerar que se puede ser responsable legalmente de los incumplimientos que tengas, ya no solo a nivel personal, si no a nivel empresa. Por ejemplo debemos pagar nominas, y cumplir con los requisitos de ley, aunque nuestro ingreso pueda ser variable.

El ingreso puede, y seguramente, sea variable, esto es por que dependemos del número de contratos que téngannos con otras empresas, así como los proyectos que tengamos en marca. También muchas empresas pueden posponer el pago, ya sea por políticas propia de la empresa, por contrato o por conveniencia. Así que es necesario que se aprendan y se usen herramientas de crédito (lo cual puede llegar a ser otro problema en el futuro).




Si te ha gustado la entrada, ¡Compártela! ;-)

sábado, 22 de agosto de 2020

Regla N°19 de la Ingeniería de Software: Enfoque en el mantenimiento y la escalabilidad antes que en la optimización

Primero haga que funcione, después hágalo rápido. Esto es cierto incluso si se está seguro de que una trozo de código es realmente importante y se sabe que será un cuello de botella es el sistema. No lo haga. Primero, consiga que el sistema tenga un diseño lo más simple posible. Entonces, si no es suficientemente rápido, optimícelo. Casi siempre descubrirá que «su» cuello de botella no es elproblema. Guarde su tiempo para lo verdaderamente importante. Bruce Eckel, Thinking in C++

Recuerdo un desarrollo donde el responsable (que no era codificador) quería optimizar al máximo la velocidad de una aplicación, era una obsesión para él. Así que se entro en una restructuración del código tras otra, con tal de obtener un poco mas de velocidad. Al final el resultado fue que se gano aproximadamente unas pocas horas de procesamiento por cada año de operación, lo que en un escenario real, viene a ser nada, por otro lado se obtuvo un código fuente completamente incomprensible y extremadamente difícil de modificar. Cuando llegaron los inevitables cambios, cada cosa que se movía era un problema nuevo, cada pequeño cambio un desastre inesperado, incluso al final el sistema comenzó a ser extremadamente lento. Al final el sistema se descarto, porque era inusable e inmantenible.

Dos términos que definen la calidad del software son la escalabilidad y la mantenibilidad, a veces son usados para referirnos al mismo aspecto del software, a que pueda “cambiar” con facilidad, y sin problemas.

  • La mantenibilidad son las modificaciones que hacemos a un sistema para que siga funcionando con el propósito para el cual fue diseñado (para resolver la necesidad de el negocio para que fue creado)
  • La escalabilidad es la facilidad con la que podemos agregar nueva funcionalidad a un software para que se adapte a las nuevas necesidades de un mercado y para que nuestro negocio no se quede estancando y obsoleto.

Hay que considerar dos cosas, y más en estos precisos momentos:

  • Todos los negocios al competir entre ellos evolucionan, cambian constantemente para adaptarse a las necesidades de sus clientes (o crear necesidades nuevas).
  • Todos estos negocios se sustentan, de una forma u otra en software que los hacen posibles.

Si el software no es capaz de adaptarse para sostener los continuos cambios de un negocio, va a fallar como sistemas y posiblemente falle el negocio siendo reemplazado por una empresa que si pueda suplir las necesidades del consumidor.

En nuestra vida profesional, vamos a estar más tiempo manteniendo software que creando software de cero. La idea de que se crea un software y nunca se va a tocar, porque “funciona bien a la primera”, es una falacia.

Aquí es donde es fundamental, que el software sea mantenible, si invertimos poco, arquitectónicamente hablando, en la construcción del software, invertiremos mucho en su mantenimiento, y viceversa. Consideran que si vamos a pasar más tiempo mantenimiento un sistema que creando, parece lógico, que debemos optar por abaratar el costo en el mantenimiento.

Volviendo al tema de la velocidad de los sistemas. La preocupación por la velocidad del software, es una “piedra en el zapato”, que a acompañado al desarrollo del software desde sus inicios. El hardware era extremadamente lento (y caro), y había que hacer software rápido, aunque sea sacrificando su propia mantenibilidad (con lo que también hacíamos software caro). Esta idea del de la necesidad de software rápido se incrusto como un paradigma inmutable en la mente de los programadores, aunque ni siquiera tuvieran que haber vivido la lentitud de un hardware tan extremo como en sus inicios.

Así parece que de forma sistemática, cada vez que ser creaba un lenguaje de programación más abstracto con el hardware, se le criticaba de forma inevitable por su lentitud. “C es más lento que ASM”, “C++ es más lento que C”, “Java es más lento que C++”, y así seguirá en un futuro, seguramente.

Las optimizaciones por obtener velocidad, pueden llegar a ser muy confusas, y a veces muy ligadas a situaciones extremadamente particulares (tanto para el software, como para el negocio). Y aquí hay que poner en una balanza varias cosas.

  • ¿Realmente mi software es lento?
  • ¿Realmente necesito que mi software sea más rápido?
  • ¿Cuál es el costo de optimizar el software? O ¿Qué voy a sacrificar para obtener más velocidad?
  • ¿Cuál es el beneficio de la optimizar el software, es real?

Aquí es donde hace sentido, la observación de Bruce Eckel, “Primero haz que funcione, después hágalo rápido”. Asegúrate siempre de programar un software bien construido, que puedas modificar fácilmente.

Un software lento, bien construido, siempre podrás modificarlo para que sea más rápido. Un software rápido mal construido, no vas a poder modificarlo.




Si te ha gustado la entrada, ¡Compártela! ;-)

Reglas de la Ingeniería de software (índice): https://desdelashorasextras.blogspot.com/2019/12/reglas-de-la-ingenieria-de-software_15.html

martes, 16 de junio de 2020

Seguridad y factores de autentificación. Casos de Fraude y Vulnerabilidades.

¿Por qué cada vez es más complicado seleccionar un password y hay cada vez más medidas y controles de seguridad?

Esto es porque dependemos más de “almacenar” y organizar nuestra vida en medios digitales, y estos datos privados adquiere un cierto valor para usarse de forma maliciosa de diversos formas, como por ejemplo robarnos el dinero que tenemos en nuestras cuentas bancarias.

Los formas tradicionales de protección se hacen obsoletos muy rápido, y las formas de obtener nuestros datos, se vuelve cada vez mas ingeniosas, y se alejan de un clásico ataque de película de hacker, en la que se usan puertas traseras o complicados códigos. La mayoría de los ataques se bajan en ingeniería social aprovechándose de la inocencia e ingenuidad (a veces de la avaricia), de los usuarios.

Vamos a analizar las formas de proteger nuestros sistemas y algunos ataques clásicos que los vulneran.


Diferencia entre privado y secreto


Ante de nada hagamos una diferencia entre que es privado y que es secreto:

  • Privado: Es un dato que solo debemos compartir con personas autorizadas, cuanto menos personas sepan este datos, más seguro es. Generalmente son datos que sirven identificarnos y se complementan con un dato secreto.

  • Secreto: Son datos que solo nosotros debemos conocer, no debemos proporcionarlos a nadie, y en el momento de usarlos debemos ser nosotros mismos los que los usemos a través de un sistema, sin ninguna iteración humana adicional.


Factores de autentificación


Los factores de autentificación son “categorías” que clasifican formas que tiene un usuario de autentificarse dentro de un sistema.

En la actualidad se debe combinar más de un factor de autentificación (más de una forma de autentificación) para garantizar la seguridad de un sistema.

Factor cero de autentificación. Algo que se sabe en común


La autentificación se basa en algo el que usuario (o cliente), y la institución (o empresa) conocen. Este dato debe ser privado, pero en muchos casos se acaba convirtiendo en un elemento público, algunos datos son:

  • Número de cuenta, cliente: Deben ser privados pero generalmente no es así, ya que es el elemento con el cual generalmente nos identifican en un primer nivel y hay que compartir.

  • Números de tarjeta: Debieran ser secretos, pero el simple de usarlas lo expone continuamente.

    Una forma muy sencilla de obtener este dato por parte de empleados maliciosos es la siguiente:

    Al momento de pagar, con papel de carbón o algún tipo de superficie que se marque con la presión, graban estos números simplemente apretando la tarjea con la superficie (recordemos que estos números tienen relieve), es algo muy rápido y pasa desapercibido porque puede estar oculto debajo de la terminal (o incluso en el pantalón) posteriormente con la excusa (o el gesto) de revisar la firma aprenden de memoria el CVE. De esta forma ya tienen el número de tarjeta, la fecha y el CVE, con lo que pueden realizar comprar por internet. Esto es muy común en comercios muy congestionados, donde la prisa se junta con el movimiento del empleado como gasolineras que no son de autoservicio.

    ¿Qué se recomienda en esto casos?:

    • Tapar el CVE, con un poco de papel, o cinta, de forma que sea imposible, revisar este número.

    • Nunca pagar con debito, si no con crédito. Es mucho más fácil ganar una reclamación cuando estas pagan con crédito (ya que le dinero nunca es tuyo y el banco se puede negar a pagar a un negocio fraudulento), que pagar con debito (donde si es tu dinero, y cuando lo pierdes, es más difícil reclamarlo).

    • No activar la compra por internet con tarjetas físicas, sino con tarjetas digitales, que ofrezcan medidas de seguridad como un CVE cambiante, y otras medidas de personalización.

    • Nunca pagar por teléfono (en un llamada telefónica) con la tarjeta.

    • Y sobre todo, nunca, nunca, perder de vista tu tarjeta, por ningún motivo, incluso, si el empleado se tarda mucho en cobrar, hay que pedir que se devuelva la tarjeta. Es común que en un escenario de fraude, el empleado haga que no entra la tarjeta y tiene que llamar a alguien o hacer una operación especial, para liberar el cobro, aprovechando para tomar los datos de la tarjeta.


  • Usuarios: Un usuario que identifica al cliente. Aunque este dato generalmente no se tiene que compartir a una persona (porque es privado y se usa generalmente dentro de sistemas), suele ser conocido por la institución (en decir en ninguna forma esta encriptado de forma no reversible) ya que es un elemento de referencia y seguimiento para distintas actividades.

  • Email o teléfono: Se usan frecuentemente y cada vez más como medios de autentificación, debido a que son fáciles de recordar, pero son extremadamente públicos, con lo cual son el primer punto de entrada para un hackeo.


El problema de este factor de autentificación es que a pesar de sus distintos niveles de privacidad, es necesario que tanto la institución, como el usuario, intercambien de forma clara el “dato”, que ambos conocen para garantizar que el otro también lo conoce, pero al hacerlo comprometemos el datos en si, por que no sabemos si realmente la persona o contraparte con lo que estamos hablando es la intuición, el cliente o solo alguien que quiere obtener dicho dato (para efectos maliciosos).

Factor uno de autentificación. Algo que solo el cliente sabe.


Generalmente aquí estamos hablando de los password, pines y demás.

  • PIN (o NIP) numérico: Es un valor numérico de cuatro o más números, que se usa para acceder a un servicio, como por ejemplo, el pago con una tarjeta.

    No ofrece en si mucha seguridad, debido a que con cuatro números, tenemos solo mil combinaciones posibles (no que no es mucho), la seguridad viene en si en que después de un numero de intentos determinado, el dispositivo o la tarjeta se bloquea (en algunos casos puede borrarse la información), lo cual es realmente lo que proporciona la seguridad.

  • Password: Es una palabra secreta que combina, letras, numero y símbolos, al igual que el pin, no se debe compartir bajo ningún concepto con otra persona.

    Tanto el password como el PIN, se guardan (o se debiera) “encriptados” en los sistemas de seguridad, con una encriptación que se llama “de una sola vía” (conocido comúnmente como hash). Esto quiere decir que no se puede llevar al valor original (el password), desencriptando el valor guardado, porque es imposible, con lo que ni la institución sabe cuál es el password que estamos usando.

    Una anécdota que me paso hace unos años con respecto a los password. Estaba con una líder de proyecto, y necesita acceder a su laptop para obtener un dato, pero ella tenía las manos ocupadas, así medio en broma le comente “voy a entrar con tu password”, y por chiripa y en medio de la broma use el nombre de su hija (ella acaba de madre recientemente), y por sorpresa la computadora de desbloqueo.

    La situación anterior, nos hace ver que sin restricción alguna, seleccionamos podemos seleccionar password que son débiles, relacionado por algún detalle de nuestra vida o contraseñas demasiado comunes que están en diccionarios para hackear contraseñas.

    Cuanta más entropía (menos orden y menos lógica) tenga un password más seguro es, con lo que se establecen una seria de restricciones a su creación, generalmente son las siguientes (cuando más se cumpla, más seguro es el password):

    • Una longitud mínima.

    • Un uso mínimo de mayúsculas y minúsculas.

    • Un uso mínimo de símbolos.

    • Un uso mínimo de números.

    • No permitir caracteres (o números) igual en secuencia, como ldquo;aaa”, o “1111”.

    • No permitir caracteres consecutivos de forma ascendente o descendente, como “1234”, “abcd” o “dcbd”.

    • No permitir palabras que se encuentren seguidas en el teclado como “qwerty”.


Una vez me preguntaron si hacer públicas esas reglas no hace que un ataque sea “más guiado” y por tanto hacer que sea más posible hackear un password. La respuesta es no, es mas hacer pública estas reglas y obligar a que sea cumplida por los usuarios (o clientes), son realmente un elemento disuasorio para los hackers, por que básicamente saben que con los medios actuales esas contraseñas son prácticamente inhackeables (aunque pueden obtenerlas mediante ingeniería social).

Factor tres de Autentificación. Algo que el cliente tiene


El usuario de autentifica con algo que solo él puede poseer, generalmente un elemento físico que se asocian a una identidad y nos permiten el acceso a una acción, característica o servicio. Algunos son:

  • Tarjetas: Las típicas tarjeas que nos permite el acceso a zonas restringidas, o para realizar pagos con ellas.

    Las tarjetas como elemento único de validación son extremadamente inseguras, deben usarse siempre junto con otro elemento.

    En México, por ejemplo, era común en la década pasada que para pagar con tarjeta solo fuera necesario presentar la tarjeta, realizar el pago con el punto de venta y firmar el voucher, en teoría el empleado debiera validad la firma y la identidad con otra autentificación, pero a pesar de ser obligatorio, era a voluntad del empleado y comúnmente nunca se hacía.

    Solo fue hasta hace poco que se comenzó a pedir el NIP de la tarjeta al realizar el pago (pero no para todas las tarjetas, ni bancos), de esta forma ya no queda a la voluntad del empleado el validar la identidad del cliente, sino que además es el cliente el que debe acreditarla, y se si equivoca varias veces, puede bloquear su tarjeta. Esta es una medida de protección fundamental para que la tarjeta no sea solo el medio de identificación posible para hacer un pago.

    Pero nada sirve totalmente, una vez mas es más sencillo realizar fraudes mediante ingeniera social, que mediante complicados y herramientas tecnológicas, como ejemplo los siguientes escenarios:

    Muchos Bancos no tiene personalizadas sus tarjetas de debito (no entiendo el motivo), con que no es fácil ubicar si una tarjeta es tuya entre dos tarjetas iguales del mismo banco, en base a eso, uno de los posibles fraudes es el siguiente:

    Una persona parece consternada cerca de un cajero (esta es el timador uno), cuando otra (este el cliente real), va a usar dicho cajero, el timador se acerca y le dice “oiga no se olvide frotar su tarjeta”, cuando el cliente se muestre perplejo, el timador insiste que debe frotar la tarjeta por qué no funciona el cajero, haciendo que se sienta cada vez mas confundido. Cuando sienta que haya bajado la guardia, le toma la tarjeta rápidamente, y le enseña con gento amable como debe frotarla y se la devuelva rápidamente, pero en el intervalo, le cambia la tarjeta por otra, al final se despide y le desea suerte, todo ocurre tan rápido que la única sensación que tiene el cliente, es que el sujeto es un poco raro y confiado.

    Cuando el cliente vaya a usar su tarjeta y le pida el NIP, es donde se acerca el timador dos, para ver disimuladamente que números está marcando. De esta manera los timadores ya tiene por separado el NIP y la tarjeta, y el cliente está confundido sin saber que ha pasado. Dándoles tiempo a los sujetos de usar las tarjetas en un negocio para compra televisiones o algún elemento de valor, que ya tendrá un tercer timado, en la fila de la caja de un comercio cercano. Todo esto puede pasar en menos de diez minutos.

    Otro timo que se puso de moda hace unos años, esta vez más sofisticado:

    Un timador, con una base de datos de teléfonos y personas (que se puede comprar ilegalmente), se hace pasar por teleoperador de un banco con muchos clientes (lo que aumenta la posibilidad de encontrar un inocente cliente).

    Llama a una víctima de sus lista, y le indica que su banco le realizo un cargo incorrecto (el teleoperador no sabe si el cliente tiene cuenta en un banco, solo es suerte y estadística).

    Le dice “por su seguridad, voy a decirle los 8 primeros números de su tarjeta)”, y aquí reside el engaño, los 8 primeros números de una tarjeta, solo indican a que banco pertenece la tarjeta, y el tipo de producto que es, esto quiere decir, que son iguales para todos los clientes.

    El cliente al ver que le han dado algunos números de su tarjeta (que no aportan realmente nada), le proporciona al timador todos los datos de su tarjeta, lleno de confianza, al pensar que habla con su banco y no con un timador. Al final, el resultado, es que de una forma u otra, el cliente se queda sin su dinero, al haber dado sus datos privados al timador.

  • Tag (Etiqueta RFID) o incluso una matrícula: Los coches pueden tener elementos como tag, que permiten la salida y entrada de vehículos (a veces incluso con reconocimiento óptico de matriculas).

    Uno de los problemas de usar un tag (o la matricula) asociado a un vehículo, es que generalmente esta pegados al mismo vehículo, con lo que se puede decir que están unidos el medio de autentificación y la acción a realizar. Esto quiere decir que por ejemplo si alguien roba tu vehículo en un estacionamiento, podrá salir con el sin más problemas (por ese falta algo más que impida esta circunstancia como un guardia o cámaras de seguridad).

  • Un teléfono: Se garantiza que la operación que se desea hacer es desde un teléfono especifico, generalmente esto se consigue de una forma parecida a la siguiente:

    1. Se genera un identificador único con datos del teléfono.
    2. Se generan claves criptografías (generalmente asimétricas).
    3. Se encriptan estos datos, usando algo mecanismo de protección como un password.

  • Un token o generador de números: Son dispositivos que genera números y se usan en cada operación, por ejemplo, si estoy haciendo una operación bancaria se pedirá un número generado por este dispositivo, y si no es el número correcto, la operación no se realizaran.

    Los dispositivos pueden ser físicos, como un aparato dedicado exclusivamente a esa función, o una aplicación instalada en un teléfono.

    Estos dispositivos, de la siguiente forma:

    1. Existe un servidor y dispositivo, ambos aislados uno de otro, sin comunicación alguna.
    2. El servidor y dispositivo, comparte una misma llave de una determinada longitud llamada semilla.
    3. Ambos generan números basándose, en la semilla (que comparten), y algún elemento independiente de ellos, como la fecha y hora exacta, esto genera un numero, como el servidor y el dispositivo generan comparte la llave, debiera poder generar el mismo número, en el mismo momento (sin tener que estar conectado).

    De esta forma el servidor sabe en cada momento que numero debe generar el dispositivo y solicitárselo al usuarios para garantizar que tiene el dispositivo consigo.

    Uno de los problemas es que el servidor (que está en la empresa que proporciona el servicio, como un banco) sabe cuáles son las semillas que generan el token, es decir es capaz de duplicar dichos números, con lo que en teoría es información que se comparte, y no es algo que tenga exclusivamente el cliente. En otras palabras quien tenga dichas semillas, se pudiera hacer pasar por el cliente.

    Otro de los problemas del token, es que el número sirve para autorizar casi cualquier cosa, con lo que podemos ser engañados, para proporcionar nuestro número actual de token, y realizar operaciones fraudulentas.


Factor tres de Autentificación. Algo que el cliente es


Algo único que está ligado a la persona física del cliente, de forma inequívoca, algo que “el cliente es”, de forma inequívoca e irrepetible, como:

  • Firmas manuscrita: es la clásica firma que hacemos de nuestro puño y letra como prueba de nuestra identidad. Es usual en contratos, y documentos impresos. Aunque se supone que es algo que solo nosotros podemos duplicar exactamente igual, generalmente puede ser copiada y no ofrece mucha seguridad (tal es el caso que en la realización de contratos generalmente hace falta una figura notarial que le de valor, y personas que funjan como testigos).

  • Elementos biométricos: Son elementos que pertenecen a nuestro cuerpo, y que pueden ser validados por un sistema informático, como

  • Huellas: Son los surcos únicos que poseemos en la llama de los dedos.

  • Rostro: Nuestra cara como identificación, el problema es que frecuentemente nuestra cara cambia, con lo que es necesario renovar la autentificación.

  • Iris del ojo: Al igual que las huellas se supone que son elementos únicos en cada uno de nosotros.

El cambio hacia los biométricos ha sido bastante arduo, por no siempre ha dado los resultados requeridos. Unos de los aspectos importantes de los biométricos (y por lo cual han sido hackeados mas de una vez), es que deben garantizar que la persona que está ofreciendo la muestra biométrica está viva y presente, por ejemplo en el caso de las caras es necesario garantizar que realmente estamos leyendo una cara, y no la foto de un sujeto, en el caso del iris, se deben observar movimientos involuntarios del ojo, para garantizarlo.

A veces el uso de biométricos puede ser frustrante, por ejemplo, Es común tener lectores de huella en los teléfonos móviles, estos lectores solemos entrenarlos con nuestra propias huellas y tener un porcentaje de éxito muy elevado, pero lectores empresariales (a veces de poco costo), que se usan másicamente en las empresas para identificar clientes, suelen dar multitud de quebraderos de cabeza.

Autentificación multifactorial


Como hemos visto cualquier solución de autentificación individual, es hackeable en cierto punto, casi siempre usando ingenio más que habilidades tecnológicas.

He aquí el por qué generalmente se usa más de una de forma de autentificación (lo que se conoce por autentificación multifactorial). Por si una es rota, quede la protección de la otra.

De misma forma las técnicas de fraude, avanzan más y de forma muy rápida, con lo que los sistemas se van mas forzados a endurecer sus mecanismos de seguridad, a expensas de la comodidad del usuario.

El principal enemigo del usuario, es su misma ingenuidad, es más fácil que el usuario proporcione sus datos de autentificación mediante engaños, que en si sea hackeado por sofisticados métodos informáticos.



Si te ha gustado la entrada, ¡Compártela! ;-)

viernes, 10 de abril de 2020

Desafíos y algoritmos. Encuentra el código


Hace unos días encontré este desafío en internet:


Se trata de encontrar un código (combinación de tres números), a través de las siguientes pistas:

  • 682: Un número es correcto y en su posición correcta.

  • 614: Un número es correcto pero mal posicionado.

  • 206: Dos números son correctos peros su posición no.

  • 738: Nada es correcto.

  • 780: Un número es correcto pero mal posicionado.

El ejercicio es ideal para resolverlo mediante varios paradigmas de programación, los cuales hemos estado revisando en los siguientes enlaces:


En este caso vamos a resolverlo usando Prolog y C, para que veamos sus diferencias:

  • Prolog es un lenguaje lógico/declarativo en que vamos expresando “hechos” o cosas que consideramos como ciertas, al final la combinación de los hechos debe darnos el resultado buscado

  • C es un leguaje imperativo/estructurado, en este tipo de lenguajes, nosotros vamos armando, paso a paso, el camino para encontrar la solución.


Solución en Prolog


Prolog es un buen lenguaje pare resolver este problema, tal como está expresado, porque tenemos una serie de pistas o circunstancia que se deben cumplir, ese conocimiento lo implementaremos en forma de reglas, dentro de nuestro programa.

Puedes ver este código y ejecutarlo en línea en https://swish.swi-prolog.org/p/EncuentraElCodigo.pl.

Cada pista será una regla, el resultado final debe cumplir todas las reglas para ser exitoso.

Cada regla, pudiera cumplirse de más de una forma, pero el resultado final debe cumplir por lo menos una

682: Un número es correcto y en su posición correcta


% 682: Un número es correcto y en su posición correcta. regla1(X,_,_):- X==6. regla1(_,X,_):- X==8. regla1(_,_,X):- X==2.

Por lo menos la regla1 debe cumplirse de una forma, ya sea que el 6, este al principio, el 8 en el medio o el 2 al final.

614: Un número es correcto pero mal posicionado


% 614: Un número es correcto pero mal posicionado. regla2(_,X,_):- X==6. regla2(_,_,X):- X==6. regla2(X,_,_):- X==1. regla2(_,_,X):- X==1. regla2(X,_,_):- X==4. regla2(_,X,_):- X==4.

Se juega con las posiciones de los números, por lo menos uno se debe cumplir.

206: Dos números son correctos peros su posición no


Regla 3 parte uno. Un número es correcto pero mal posicionado.

% Regla 3 parte uno. Un numero es correcto pero mal posicionado regla3a(_,X,_):- X==2. regla3a(_,_,X):- X==2. regla3b(X,_,_):- X==0. regla3b(_,_,X):- X==0. regla3c(X,_,_):- X==6. regla3c(_,X,_):- X==6.

Regla 3 parte dos. Dos números son correctos, con lo que deben cumplirse dos reglas de las anteriores.

regla3(A,B,C):- regla3a(A,B,C), regla3b(A,B,C). regla3(A,B,C):- regla3a(A,B,C), regla3c(A,B,C). regla3(A,B,C):- regla3b(A,B,C), regla3c(A,B,C).

738: Nada es correcto


% 738: Nada es correcto. regla4(X,Y,Z):- not(member(7,[X,Y,Z])), not(member(3,[X,Y,Z])), not(member(8,[X,Y,Z])).

Esta es la regla más sencilla, no puede contener ni 7, ni 3, ni 8.

780: Un número es correcto pero mal posicionado


% 780: Un número es correcto pero mal posicionado regla5(_,X,_):- X==7. regla5(_,_,X):- X==7. regla5(X,_,_):- X==8. regla5(_,_,X):- X==8. regla5(X,_,_):- X==0. regla5(_,X,_):- X==0.

Esta regla es igual que la regla 2.

El código final (el resultado): Debe cumplir la todas las reglas


% El codigo debe complir todas las reglas codigo(X,Y,Z):- regla1(X,Y,Z), regla2(X,Y,Z), regla3(X,Y,Z), regla4(X,Y,Z), regla5(X,Y,Z).

Comprobación de los resultados


Genero los posibles resultado en un matriz (que van de 000 a 888).

% Genero los posibles resultados,segun las pistas, deben ser % 0,1,2,3,4,6,7,8 (curiosamente no esta el 5, ni el 9) % crea una coleccion de matrices que va desde [0,0,0] a [8,8,8] posiblesResultados(R):- M=[0,1,2,3,4,6,7,8], findall(N,member(N,M),L), findall([X,Y,Z],(member(X,L),member(Y,L),member(Z,L)),R).

Busco el código final, entre todos los resultados

% De los posibles resultados, busca los que cumplan el codigo buscarCodigo(R):- posiblesResultados(M), findall(L, (member(L,M), codigo(L)),R). /* Resultados ?- buscarCodigo(R). R = [[0, 4, 2], [0, 6, 2]] El resultado 042 cumple todas las reglas. El resultado 062 tambien las cumple, de forma no excluyente. */

Los números que cumplen todos los criterios son el 042 y el 062

El número 062 es válido, si considerarnos como no excluyentes las pistas. Por ejemplo en la primera pista 682: Un número es correcto y en su posición correcta, no consideramos que solo uno es correcto, si no que por lo menos uno. Si los consideramos excluyentes, debiéramos implementar nuevas reglas para tal efecto y solo seria valido el 042,

Solución en C


Haber solucionado el problema en Prolog previamente nos da un indicio de cómo debe solucionarse con otra aproximaciones, en generar se puede estructurar en pequeñas soluciones parciales llamadas reglas y el código final debe cumplir todas las reglas.

Puedes revisar y ejecutar el código en https://repl.it/@JoseLuisLuis65/EncuentraElCodigo

El problema en C lo resolveremos de la siguiente forma:

  • Crearemos pequeñas tablas de conocimiento, que nos definan que escenarios son posibles, cada fila en cada escenario representa un valor posible.

  • Cada regla tendrá definido una tabla de conocimiento, por lo menos debe cumplirse un escenario de la tabla.

  • Al final debe cumplirse todas las reglas, para obtener el resultado.


682: Un número es correcto y en su posición correcta


// 682: Un número es correcto y en su posición correcta. bool regla1(int x, int y, int z) { int validos[3][3] = { { 6, X, X }, { X, 8, X }, { X, X, 2 } }; return validar(validos, 3, x, y, z); }

614: Un número es correcto pero mal posicionado


// 614: Un número es correcto pero mal posicionado. bool regla2(int x, int y, int z) { int validos[6][3] = { { X, 6, X }, { X, X, 6 }, { 1, X, X }, { X, X, 1 }, { 4, X, X }, { X, 4, X } }; return validar(validos, 6, x, y, z); }

206: Dos números son correctos peros su posición no


// 206: Dos números son correctos peros su posición no bool regla3(int x, int y, int z) { int validos1[2][3] = { { X, 2, X }, { X, X, 2 }, }; int validos2[2][3] = { { 0, X, X }, { X, X, 0 }, }; int validos3[2][3] = { { 6, X, X }, { X, 6, X }, }; bool valido = (validar(validos1, 2, x, y, z) && validar(validos2, 2, x, y, z)) || (validar(validos1, 2, x, y, z) && validar(validos3, 2, x, y, z)) || (validar(validos2, 2, x, y, z) && validar(validos3, 2, x, y, z)); return valido; }

738: Nada es correcto


// 706: Nada es correcto. bool regla4(int x, int y, int z) { int invalidos[] = { 7, 3, 8 }; int valores[] = { x, y, z }; for (int i = 0; i < 3; i++) for (int j = 0; j < 3; j++) if (invalidos[i] == valores[j]) return false; return true; }

780: Un número es correcto pero mal posicionado

// 780: Un número es correcto pero mal posicionado bool regla5(int x, int y, int z) { int validos[6][3] = { { X, 7, X }, { X, X, 7 }, { 8, X, X }, { X, X, 8 }, { 0, X, X }, { X, 0, X } }; return validar(validos, 6, x, y, z); }

El código final (el resultado): Debe cumplir la todas las reglas


bool codigo(int x, int y, int z) { return regla1(x, y, z) && regla2(x, y, z) && regla3(x, y, z) && regla4(x, y, z) && regla5(x, y, z); }

La siguiente función comprueba que por lo menos una fila sea exitosa, de cada tabla de posibles soluciones.

bool validar(int validos[][3], int filas, int x, int y, int z) { //Veo si alguna fila es valida for (int i = 0; i < filas; i++) { bool valido = (validos[i][0] == X || validos[i][0] == x) && (validos[i][1] == X || validos[i][1] == y) && (validos[i][2] == X || validos[i][2] == z); if (valido) return true; } // Ninguna es valida return false; }

Comprobación de los resultados


int main(void) { const int MAX_POSIBLES = 8; // Genero los posibles resultados,segun las pistas, deben ser // 0,1,2,3,4,6,7,8 (curiosamente no esta el 5, ni el 9) int posibles[] = { 0, 1, 2, 3, 4, 6, 7, 8 }; // Recorro todas las posibles soluciones y veo las que tengan exito for (int i = 0; i < MAX_POSIBLES; i++) for (int j = 0; j < MAX_POSIBLES; j++) for (int k = 0; k < MAX_POSIBLES; k++) if (codigo(i, j, k)) printf("[%d %d %d] ", i, j, k); return 0; }

Conclusiones



La solución en Prolog, parece mas sencilla de implementar, dada la naturaleza declarativa del lenguaje, y que el problema en sí consiste en que se deben cumplir una seria de reglas (especialidad de Prolog).

Comparando los tamaños de los archivos en líneas código obtenemos la siguiente grafica.


Es decir para resolver el problema necesitamos 86 líneas en Prolog y 150 en c, comparando porcentajes seria así:


Con lo que podemos concluir que es más conciso resolver este tipo de problemas usando Prolog, que usando C.




Si te ha gustado la entrada, ¡Compártela! ;-)

Nota: Puedes encontrar todo el código fuente de este artículo en https://github.com/jbautistamartin/ParadigmasTiposLenguajes