Lo que veis en la foto es un arduino beeetle, bueno, realmente es una placa pro micro con menos pines de los que debería y un conector directo a usb… Como véis es muy pequeño y podéis encontrarlo por un precio bastante económico, aquí, por ejemplo.
Yo ya había utilizado antes el arduino pro micro (leonardo compatible) para simular un teclado en otro proyecto, por lo que sabía que podría utilizar este también para algo similar. Dado su tamaño y lo fácil que se camufla como un «pincho» usb podría pasar desapercibido a la vista… Así que me decidí a ir un pasito más y añadirle un poco más de hardware para controlarlo. Qué mejor que ponerle un botón para indicarle cuando quiero que «teclee algo»… Para ello me aprovecho de que los pines digitales pueden actuar como pull-up y solo tenía que conectar el interruptor entre un pin digital y tierra. En mi caso lo conecté entre el D9 y GND como se puede ver en la foto:
Hice las soldaduras por detrás para proteger un poco más los componentes, pero podría ponerse por delante teniendo un poco más de cuidado.
Una vez el hardware preparado llega el momento de hacer las cosas interesantes… Tampoco es que vaya a ser muy original, pero aquí os dejo el programa que cargué inicialmente…. Funciona en windows y lo que consigues cuando pulsas el botón es que se te abra el chrome con la página web nomorepass.com… (igual sirve como propaganda y todo).
Básicamente lo único que hace es esperar a que el estado del pin al que está conectado el botón pase de alto a bajo (esto es así por la configuración INPUT_PULLUP) y cuando cambia, señal de que hemos pulsado el botón, lo que hace es enviar un COMMAND+r que abre el diálogo de ejecutar de windows y luego envía el texto chrome https://nomorepass.com. Como se puede ver he tenido que transliterar los caracteres que en el teclado americano están colocados en otro sitio (un defectillo de la librería de arduino).
Visto que funciona… Pues ya solo queda hacer una cajita e imprimirla en 3d:
He dejado el diseño en thingiverse por lo que podéis aprovecharlo… Mientras, a inventarnos cosas que hacer con el trasto… «No demasiado diabólicas»..
Ahora que ya acabas de construir una librería interesante en Java, la has hecho pública (en github, por ejemplo) y quieres que todo el mundo la use… Queda una tarea pendiente, subirla a un repositorio maven para ponerla a disposición de los que utilicen este sistema (o gradle, que hoy en día ya son casi todos).
Vamos a verlo con un ejemplo que he subido esta mañana… Hay cosas que todavía no entiendo del todo, pero el resultado ha sido bueno, por lo que, al menos, podremos usar esta receta como guía para próximas veces.
El código que intento subir es una librería simple que tengo alojada en github con su pom.xml básico y que si te descargas el proyecto podrías compilar e instalar en tu maven con mvn install. La dirección es esta:
https://github.com/yoprogramo/nomorepass-java/
Ahora, para que todo el mundo pueda descargárselo como dependencia y no tenga que hacer el mvn install del proyecto, tenemos que subirlo a un repositorio público, podemos ver una guía en esta página: Guide to Public Maven Repositories. Tal como explican en la página, lo más sencillo para publicar en Maven Central es usar el repositorio Sonatype. Dicho y hecho… Lo intentamos por aquí.
Lo primero es crear una cuenta en el Jira de Sonatype aquí. Lo siguiente, y esto es un poco «tricky» es crear un ticket solicitando un nuevo id de grupo en esta dirección. No se puede pedir cualquier id de grupo (en mi caso quería pedir com.nomorepass) y generalmente se pedirá alguna prueba de que el dominio es tuyo. En mi caso este es el ticket que creé: https://issues.sonatype.org/browse/OSSRH-49426, para demostrar que el dominio era mío cambié el DNS e incluí una entrada TXT con el identificador del ticket:
Una vez autorizado (tarda un poco, es un proceso manual) hay que modificar nuestro código y prepararlo para la subida, pero, antes de eso, tenemos que generar nuestras claves gpg para poder firmar el código. eso se hace con este comando:
gpg --gen-key
Una vez generada podremos acceder a la lista de claves con el comando:
gpg --list-keys
Toma nota del id de la clave y recuerda la contraseña que usaste para generarla, porque tendrás que recordarla. Además, tendrás que publicarla en algún servidor de claves públicas para que pueda ser comprobada.
Si todo ha ido bien, el artefacto estará subido a un repositorio que tendremos que promocionar a «Release» para que se sincronice con el repositorio central… Pero al final ya lo tendremos disponible para todo el mundo…
Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.
El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una «feliz transición». El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.
¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?
Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:
<Directory /directorio.de.la.web/.git>
Options FollowSymLinks
AllowOverride All
Require all denied
</Directory>
Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.
Y con esto y un bizcocho… Podemos empezar nuestra semana.
Lo digo muchas veces, pero yo ya soy viejuno en esto de internet. Mi primera cuenta de correo electrónico me la abrieron en 1989 (si, la web no se había inventado todavía) y tuve la suerte de ser el administrador de la red del laboratorio de investigación en el que estaba estudiando, lo que me dió la oportunidad de configurar y usar las news de internet (a alguno ya ni les sonará). El caso es que llevo el tiempo suficiente surfeando la ola de internet como para tener una perspectiva amplia en esto de «la red».
El caso es que ayer llegó a mis oídos la noticia Mother of All Breaches Exposes 773 Million Emails, 21 Million Passwords, que viene a decir que se ha encontrado una colección de archivos que recopilan 772.904.991 direcciones de correo y 21.222.975 passwords distintos. ¿Qué significa esto? Básicamente que si no has cambiado tu contraseña durante mucho tiempo en alguno de los servicios menos seguros de la red (aquellos que hayan tenido alguna fuga de datos) es casi seguro que cualquiera pueda saber cual es tu contraseña. De hecho, las últimas noticias indican que ese archivo es parte de un conjunto más grande con 1TB de contraseñas….
Hace unos años esto no sería mayor problema, la contraseña era una cosa que nos forzaban a elegir y que, en el mejor de los casos, nosotros seleccionabamos de una manera «regular», siempre la misma que creíamos segura, una variación de esa contraseña segura o lo primero que se nos pasaba por la cabeza y que terminábamos apuntando en un papel, total, ¿quién va a querer acceder a mis datos? Pero hoy en día la cosa ha cambiado muchísimo. La mayoría de nosotros ya no vamos al banco, sino que operamos via internet, compramos cada día en internet por más y más cantidad, pedimos las citas para el médico, compramos las entradas para el cine, los viajes, alquilamos las vacaciones… Y todo ello utilizando las contraseñas a las que, desgraciadamente, hemos prestado tan poca atención.
El principio básico en que se basa toda nuestra vida digital es que nosotros podemos almacenar en nuestro cerebro las contraseñas que necesitemos, pero eso ya no es válido. Cada día usamos más contraseñas de más servicios y eso hace físicamente imposible que las memoricemos… ¿hay solución?
Ninguna 100% fiable. Los gestores de contraseñas tradicionales (1password, dashlane, etc.) utilizan bases de datos centralizadas que son, como poco, golosinas demasiado irresistibles para los hackers y se convierten en destino de ataques que ya han conseguido éxito alguna que otra vez. Por eso, y hasta que se encuentren métodos más seguros para autorizarnos a acceder a nuestros servicios se me ocurrió construir nomorepass. El único servicio que mantiene seguras las contraseñas en el móvil y no las almacena en ninguna base de datos central. Además, te da todos los medios para que no tengas que teclear esas contraseñas nunca… Lo que te permite tener contraseñas seguras, distintas y sin tener que recordarlas.
En serio, tenéis que probarla. A mi me ha solucionado el problema de las contraseñas para siempre… Y, además, no tienes que fiarte de nadie porque nadie tiene tus contraseñas.
Gestionar el consentimiento de las cookies
Si, es un coñazo, pero tengo que ponerte este aviso sobre las cookies y mi
Funcional
Siempre activo
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.
Preferencias
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario.
Estadísticas
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos.El almacenamiento o acceso técnico que se utiliza exclusivamente con fines estadísticos anónimos. Sin un requerimiento, el cumplimiento voluntario por parte de tu Proveedor de servicios de Internet, o los registros adicionales de un tercero, la información almacenada o recuperada sólo para este propósito no se puede utilizar para identificarte.
Marketing
El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.