DEV Community: newton

Entendendo TOTP

newton — Mon, 02 Sep 2024 16:50:18 +0000

Com o aumento dos ataques cibernéticos, torna-se cada vez mais necessário adotar ferramentas e hábitos que dificultem o acesso de pessoas mal-intencionadas aos seus dados. Uma estratégia amplamente utilizada é a autenticação de dois fatores (2FA). Hoje, vamos explorar mais a fundo uma das diversas alternativas de segundo fator disponíveis no mercado: o TOTP.

O que é TOTP?

TOTP é a sigla para Time-Based One-Time Password Algorithm, um algoritmo utilizado para gerar senhas únicas baseadas no tempo. De acordo com a RFC 6238, ele é uma extensão do algoritmo HMAC-based One-Time Password (HOTP) descrito na RFC 4226, que também gera senhas seguras e únicas, mas é baseado em um contador, e não no tempo.

Como funciona o algoritmo?

Como mencionamos, o TOTP é uma extensão do HOTP, então, para entendê-lo melhor, vamos primeiro compreender como o HOTP funciona. O HOTP segue os passos abaixo, de forma simplificada, para gerar uma senha de uso único:

O servidor gera uma chave secreta para cada usuário.
O usuário armazena essa chave em um dispositivo.
A cada nova senha gerada, o contador é incrementado.

A fórmula pode ser definida da seguinte maneira:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C))

onde:

K é a chave secreta.
C é o contador, que deve estar sincronizado entre o servidor e o cliente.
Truncate é uma função que converte o resultado do hash em um número amigável para o usuário.

Como discutimos anteriormente, a principal diferença entre o HOTP e o TOTP é o uso do tempo. A fórmula para o TOTP pode ser definida como:

TOTP = HMAC(K, T)

onde T representa o tempo. O tempo é calculado usando a seguinte fórmula:

T = floor(Current Unix time / step)

Mas o que é o step? Bem, não somos rápidos como o Relâmpago McQueen para gerar um código e inseri-lo no servidor no mesmo segundo. Portanto, é importante ter uma janela de tempo durante a qual o usuário possa gerar uma senha e inseri-la no servidor. Um valor comum para esse intervalo é de 30 segundos.

A função Truncate é um pouco mais complexa, mas o algoritmo está detalhado na seção 5.4 da RFC 4226. Em termos simplificados, os passos são:

Obter um offset, que é definido pelos 4 últimos bits do último byte do hash gerado.
Extrair 31 bits a partir do offset.
Realizar uma operação de módulo para obter o valor amigável.

Exemplo de implementação em Elixir

defmodule TOTP do
  @duration 30
  @digit_count 6

  import Bitwise

  @spec generate_secret() :: binary()
  def generate_secret do
    :crypto.strong_rand_bytes(20) |> Base.encode32
  end

  @spec generate_totp(binary()) :: binary()
  def generate_totp(key) do
    {:ok, key} = Base.decode32(key)
    key
    |> hmac(calculate_T())
    |> truncate()
  end

  @spec valid?(binary(), any()) :: boolean()
  def valid?(secret, otp, since \\ nil),
    do: otp == generate_totp(secret) and not has_been_used?(since)

  #RFC4226 https://datatracker.ietf.org/doc/html/rfc4226#section-5.4
  defp truncate(hash) do
    # getting the last byte and masking it so we get a valid index
    offset = :binary.last(hash) &&& 0x0F
    # Extract 4 bytes starting from the calculated offset
    <<_::binary-size(offset), extracted_value::integer-size(32), _rest::binary>> = hash

    # Ensure the extracted value is positive
    extracted_positive_value = extracted_value &&& 0x7FFFFFFF

    # taking this number module to get the 06 digits
    otp = rem(extracted_positive_value, :math.pow(10, @digit_count) |> round())

    formatted_otp =
      otp
      |> Integer.to_string()
      |> String.pad_leading(6, "0")

    formatted_otp
  end

  defp hmac(key, t) do
    :crypto.mac(:hmac, :sha, key, t)
  end

  defp calculate_T(), do: <<Integer.floor_div(now_unix(), @duration)::64>>

  defp has_been_used?(nil), do: false

  defp has_been_used?(since),
    do: Integer.floor_div(now_unix(), @duration) <= Integer.floor_div(since, @duration)

  defp now_unix(), do: DateTime.utc_now() |> DateTime.to_unix()
end

Nessa implementação, estamos seguindo os passos mencionados anteriormente. Temos 3 funções principais:

TOTP.generate_secret/0: Gera uma chave secreta para o usuário. Essa chave deve ser armazenada de forma segura pelo servidor para validar a solução gerada pelo usuário. Do lado do usuário, a chave deve ser importada em algum aplicativo no dispositivo, como o Google Authenticator. Para evitar que o usuário insira manualmente a chave, uma solução comum é permitir que ele escaneie um QR code.
TOTP.generate_totp/1: Recebe a chave do usuário e aplica o algoritmo que aprendemos anteriormente. Calcula o hash com base no tempo e formata o hash para um valor amigável.
TOTP.valid?/2: Recebe o código inserido pelo usuário e o confronta com o código gerado pelo servidor.

Conclusão

Podemos observar que o custo para realizar a autenticação de dois fatores utilizando TOTP é baixo comparado a outras formas como SMS, email e afins, que além de terem o custo para o envio da notificação, apresentam a possibilidade de interceptações durante o processo, além de exigir conexão com a internet ou sinal telefônico. Já o TOTP pode ser gerado pelo dispositivo, por exemplo em um celular, mesmo que ele não tenha nenhum desses requisitos.

Integrando um BFF Rest com um microsserviço via gRPC

newton — Sat, 09 Dec 2023 23:59:18 +0000

Informações iniciais

Neste texto, abordaremos o gRPC e como integrá-lo em uma arquitetura que utiliza BFFs (Backend For Frontend). A compreensão será mais proveitosa se o leitor acompanhar o repositório no Github para explorar as pastas do projeto.

O que é um BFF?

Backend For Frontend (BFF) refere-se a uma camada responsável por intermediar as requisições entre o cliente e o servidor, agregando informações de diferentes serviços, tratando os dados e permitindo atender necessidades específicas de cada cliente.

gRPC

O gRPC é um framework desenvolvido pela Google para facilitar comunicações entre serviços, utilizando um protocolo de contrato bem definido, Protocol Buffers (protobuf).

Definição de contrato

A primeira etapa para começarmos a utilizar gRPC é instalar o protoc na máquina e definir nosso serviço. Nosso serviço é definido da seguinte forma:

syntax = "proto3";

package grpc_example;

option go_package = "../proto_schemas";

service User {
  rpc Create (CreateRequest) returns (UserReply) {}
  rpc Get (GetRequest) returns (UserReply) {}
}

message UserReply {
  int32 id = 1;
  string email = 2;
  string name = 3;
}

message CreateRequest {
  string email = 1;
  string name = 2;
}

message GetRequest {
  int32 id = 1;
}

Onde:

User é nosso serviço composto por duas funções: Create e Get
UserReply é nosso contrato de resposta, o que nosso serviço retorna após executar a função
CreateRequest e GetRequest são os payloads esperados em cada função

Com o contrato definido, executamos os comandos:

make generate-elixir-proto
make generate-go-proto

Esses comandos criarão as estruturas de cada linguagem. Cada linguagem necessitará de seus respectivos plugins para o protoc criar os arquivos. Os plugins podem ser encontrados em Protobuf.dev.

Criando o servidor gRPC

Com o contrato criado e os módulos e estruturas gerados, podemos desenvolver nossa aplicação. A pasta grpc_server contém nosso código Elixir com um servidor gRPC implementado. Começamos importando os módulos gerados na etapa anterior, como pode ser visto no arquivo grpc_server/mix.exs. Após isso, desenvolvemos nosso endpoint.

defmodule App.Endpoint do
  use GRPC.Endpoint

  intercept GRPC.Logger.Server
  run App.GrpcServer
end

Neste código, especificamos que nosso handler será o módulo customizado App.GrpcServer.

defmodule App.GrpcServer do
  alias Repository.UserRepository
  require Logger
  use GRPC.Server, service: GrpcExample.User.Service

  def create(request, _stream) do
    Logger.info("Received create request")
    new_user =
      UserRepository.save(%{
        name: request.name,
        email: request.email,
      })

    GrpcExample.UserReply.new(new_user)
  end

  def get(request, _stream) do
    user = UserRepository.get(request.id)
    Logger.info("Received get request")
    if user == nil do
      raise GRPC.RPCError, status: :not_found
    else
      GrpcExample.UserReply.new(user)
    end
  end
end

Esse módulo implementa as duas funções especificadas em nosso contrato e retorna os tipos definidos. Com isso, podemos executar nosso endpoint na porta 9000 e teremos uma aplicação pronta para receber requisições gRPC.

defmodule App.Application do
  @moduledoc false
alias Repository.UserRepository

  use Application

  @impl true
  def start(_type, _args) do
    children = [
      UserRepository,
      {GRPC.Server.Supervisor, {App.Endpoint, 9000}}
    ]

    opts = [strategy: :one_for_one, name: App.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

Criando BFF em Go para consumir servidor gRPC

Com nosso servidor gRPC em Elixir disponível, criaremos uma API Rest que será utilizada pelo nosso frontend para consumir informações do serviço que busca e cria usuários.

package main

import (
    "log"
    "net/http"
    "strconv"

    "example.com/grpc_example/proto_schemas"
    "github.com/gin-gonic/gin"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
)

var (
    addr            = "server:9000"
    grpc_connection *grpc.ClientConn
)

func main() {
    conn, err := grpc.Dial(addr, grpc.WithTransportCredentials(insecure.NewCredentials()))
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }

    grpc_connection = conn
    defer conn.Close()

    r := gin.Default()
    r.GET("/users/:id", get_user)
    r.POST("/users/", insert_user)
    r.Run()
}

func get_user(c *gin.Context) {
    user_client := proto_schemas.NewUserClient(grpc_connection)

    id, err := strconv.Atoi(c.Param("id"))

    if err != nil {
        c.Status(http.StatusUnprocessableEntity)
        return
    }

    r, err := user_client.Get(c.Request.Context(), &proto_schemas.GetRequest{
        Id: int32(id),
    })

    if err != nil {
        c.JSON(http.StatusNotFound, gin.H{
            "message": err.Error(),
        })
        return
    }

    c.JSON(http.StatusOK, gin.H{
        "id":    r.Id,
        "name":  r.Name,
        "email": r.Email,
    })
}

type user_insert_request struct {
    Name  string
    Email string
}

func insert_user(c *gin.Context) {
    user_client := proto_schemas.NewUserClient(grpc_connection)

    var request *user_insert_request
    if err := c.ShouldBindJSON(&request); err != nil {
        c.Status(http.StatusUnprocessableEntity)
        return
    }

    r, err := user_client.Create(c.Request.Context(), &proto_schemas.CreateRequest{
        Email: request.Email,
        Name:  request.Name,
    })

    if err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{
            "message": err.Error(),
        })
        return
    }

    c.JSON(http.StatusCreated, gin.H{
        "id":    r.Id,
        "name":  r.Name,
        "email": r.Email,
    })
}

Nossa função main é responsável por criar a conexão com o servidor gRPC e disponibilizar um servidor web com duas rotas. Essas rotas executarão funções específicas, validarão o payload de entrada, enviarão a requisição via gRPC para o serviço em Elixir, verificarão se houve algum erro nesse processo e retornarão o JSON esperado de saída.

gRPC vs Rest

O gRPC é a melhor alternativa para comunicações entre serviços? Bem, em minha opinião, é uma excelente alternativa para comunicações entre serviços que não dependem de entrada do cliente, uma vez que o suporte para navegadores ainda é limitado. Por outro lado, em uma companhia com diversos serviços que trocam informações constantemente, o gRPC pode ser uma excelente alternativa para diminuir o tráfego de dados pela rede devido ao uso dos protobufs no lugar de JSON e/ou XML, que exigem maior esforço para deserializar. Além disso, oferece maior agilidade para o desenvolvimento entre as equipes, já que a geração de código ocorre de forma ágil com o auxílio do protoc. No entanto, a escolha entre tecnologias depende de fatores como familiaridade da equipe e disponibilidade para migração.

Executando o projeto

Após clonar o projeto em sua máquina, utilize o comando:

make docker-up

Assim, poderá realizar requisições como as abaixo:

Criação de usuário:

curl --location 'localhost:8080/users' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "teste",
    "email" : "teste@teste.com"
}'

Resposta:

{
    "email": "teste@teste.com",
    "id": 1,
    "name": "teste"
}

Busca de usuário por ID:

curl --location --request GET 'localhost:8080/users/1' \
--header 'Content-Type: application/json

Resposta:

{
    "email": "teste@teste.com",
    "id": 1,
    "name": "teste"
}