Archivo de la categoría: internet

Nueva versión de nomorepass

Posted on por
Responder

No suelo escribir aquí sobre estas cosas, pero hacía tiempo que no sacábamos ninguna novedad en nuestro gestor de contraseñas y como ahora mismo tenemos la versión 1.16.6 recién salida del horno en ambas tiendas (es raro que podamos lanzar a la vez en Android e iOs) pues os hago un reumen de lo que podéis encontrar nuevo (y mejorado).

Por fin la Wifi

Desde hace mucho tiempo nomorepass nos permite escanear los códigos QR con los que se comparten las credenciales de la WiFi, usar esas contraseñas era otra historia, o bien lo hacíamos con el sistema autofill de android, del que ya hablamos aquí, o bien copiabamos y pegábamos la contraseña en el diálogo de cambiar Wifi… Bien, esto ha cambiado y ahora ya podrás usar la contraseña de la wifi directamente desde la app.

Aquí te cuento como:

Como ves, nada más sencillo ahora que ya está integrado. En iOS funciona exactamente igual salvo que nos pedirá consentimiento antes y tarda un poco más en hacer efectivo el cambio.

Recuperar el backup que quieras

Tener tus contraseñas solo en el móvil es algo que requiere tener muy bien organizadas las copias de seguridad para que, en caso de percance, se puedan recuperar todas las contraseñas. Hasta ahora se almacenaban todas las copias asociadas al dispositivo que hacía las copias, de manera que no se podía recuperar una copia de seguridad de otro dispositivo en uno que ya había hecho alguna copia (me estoy refiriendo a copias en la nube, claro). Esto ha cambiado en esta versión como se cuenta en el mismo sitio web.

Ahora, cuando se solicita restaurar una copia de seguridad en la nube se nos ofrece la opción de elegir qué copia de seguridad queremos recuperar (y se marca con una barrita en la izquierda cual es la última copia que se hizo desde el dispositivo):

Además de la fecha se indica el «peso» que tiene el archivo, así evitaremos recuperar copias de seguridad de otros dispositivos con menos contraseñas…

Y eso es todo, espero que disfrutéis de esta nueva versión y, ya sabéis, cualquier problema se lo podéis consultar a [email protected].

Subir a maven central una librería propia

Posted on por
Responder

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.

gpg --keyserver hkp://keys.gnupg.net --send-keys <el-id-de-la-clave>

Ahora empezamos a modificar el pom.xml para que cumpla con los requisitos para el repositorio Maven Central. En nuestro caso pusimos esto:

<groupId>com.nomorepass</groupId>
  <artifactId>nomorepass</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <name>Nomorepass java library</name>
  <description>NoMorePass protocol 2 implemented on Java.</description>
  <url>https://nomorepass.com</url>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <developers>
    <developer>
      <name>Jose Antonio Espinosa</name>
      <email>[email protected]</email>
      <organization>Nomorepass</organization>
      <organizationUrl>https://nomorepass.com</organizationUrl>
    </developer>
  </developers>

  <scm>
    <connection>scm:git:git://github.com/yoprogramo/nomorepass-java.git</connection>
    <developerConnection>scm:git:ssh://github.com:yoprogramo/nomorepass-java.git</developerConnection>
    <url>https://github.com/yoprogramo/nomorepass-java/tree/master</url>
</scm>

Y, una vez informado de todo esto, hay que incluir los plugins que nos permitirán hacer el despliegue directamente. Yo añadí esto:

<distributionManagement>
    <snapshotRepository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </snapshotRepository>
    <repository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
    </repository>
</distributionManagement>

Y puse en mi directorio de maven settings.xml los datos de mi usuario 

<settings>
  <servers>
    <server>
      <id>ossrh</id>
      <username>xxxxxxxxxx</username>
      <password>xxxxxxxxxx</password>
    </server>
  </servers>
</settings>

Por último, toda la sección de build (que no tenía) la sustituí por esto:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-gpg-plugin</artifactId>
        <executions>
          <execution>
            <id>sign-artifacts</id>
            <phase>verify</phase>
            <goals>
              <goal>sign</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.sonatype.plugins</groupId>
        <artifactId>nexus-staging-maven-plugin</artifactId>
        <version>1.6.7</version>
        <extensions>true</extensions>
        <configuration>
          <serverId>ossrh</serverId>
          <nexusUrl>https://oss.sonatype.org/</nexusUrl>
          <autoReleaseAfterClose>true</autoReleaseAfterClose>
        </configuration>
      </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-source-plugin</artifactId>
          <version>2.2.1</version>
          <executions>
            <execution>
              <id>attach-sources</id>
              <goals>
                <goal>jar-no-fork</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-javadoc-plugin</artifactId>
          <version>2.9.1</version>
          <executions>
            <execution>
              <id>attach-javadocs</id>
              <goals>
                <goal>jar</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
    </plugins>
</build>

Y ya, finalmente, pude ejecutar el mágico:

mvn clean deploy

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…

Aquí podéis encontrar lo que acabo de subir: https://search.maven.org/artifact/com.nomorepass/nomorepass/1.0/jar

Protege tu .git

Posted on por
Responder

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.

¿Seguridad en la red?

Posted on por
Responder

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.