Servicio de usuario securizado

[pavel-kalmykov]

Descripción

Debemos de externalizar el modelo del usuario, y para ello crearemos un servicio tipo REST.

Condiciones de aceptación

Creación de usuarios

• [x] Tener terminada las issues #1 #4, ya que de alguna manera tendremos que poder enviar los datos del usuario para que el servidor los guarde.
• [x] El servidor deberá de recibir por petición POST en el endpoint "/users" un JSON de la entidad User descrita en el diagrama con el nombre de usuario y la contraseña ya hasheada (con SHA-512) desde el cliente. Si falta algún dato o la contraseña viene sin cifrar, se devolverá un HTTP 400 Bad Request especificando cuál ha sido exactamente el error producido.
• [x] Si el usuario ha sido enviado correctamente, hashearemos la contraseña (otra vez) con salteado utilizando el algoritmo bcrypt.
• [x] Por último, cada uno de los campos los cifraremos con cifrado AES-256 (porque va mejor en 64 bits) con una clave que vendrá dada de forma global por el entorno del programa (no estará hardcodeada en el código).
• [x] Una vez creemos el usuario, deberemos de devolver una respuesta típica de un API REST cuando un recurso nuevo es creado.

  Listado, detalles, edición, borrado

  De momento no requeriremos autenticación para acceder a estos endpoints.

  1. Deberemos de poder realizar listados, detalles de un usuario, edición y borrado del mismo siguiendo los principios REST.
  2. En cuanto la edición, seguiremos el mismo procedimiento que en la creación.
  3. Tanto en el listado como en los detalles, las contraseñas no las mandaremos al cliente, aunque estén encriptadas.

Referencias

• Cómo almacenan las contraseñas en Dropbox
• Diseño de APIs REST (hasta la página 13)

[pavel-kalmykov]

Desarrollando en servicio-registro-login

[pavel-kalmykov]

Se utilizará una implementación de AES en modo CTR, basada en la solución proporcionada en el Gist https://gist.github.com/manishtpatel/8222606.

La clave de este pepper o pimienta de momento la guardamos en el propio fichero fuente en donde reside esta implementación. Se deberá de diseñar un sistema a través del cual podamos recuperar esta clave de forma externa, pero en otra issue diferente.

[pavel-kalmykov]

Debido a la migración que se hizo en #4, la columna password de la tabla users es de tipo varchar(60). Usando el cifrado AES, la contraseña cifrada queda en 104 caracteres usando Base64, haciendo la inserción de usuarios imposible de esta forma.

Vamos a cambiar el tipo de esa columna por varchar (o text), que viene siendo exactamente el mismo tipo que varchar(60) pero sin límite de carácteres (PostgreSQL no penaliza el no tener límite)

[pavel-kalmykov]

Para probar los Handlers de cada endpoint del controlador de usuarios, hemos utilizado la librería gofight en conjunto con el nuevo servidor HTTP Gin