Pular para o conteúdo principal

Postagem em destaque

BlackTDN :: Autenticação 2FA para Usuário Root no WSL

--- # naldodj-wsl-2FA ## Autenticação 2FA para Usuário Root no WSL ### Introdução O Windows Subsystem for Linux (WSL) é uma ferramenta poderosa que permite aos desenvolvedores executar um ambiente Linux diretamente no Windows. No entanto, a segurança é uma preocupação importante, especialmente quando se trata de acessar o usuário root. Neste post, vamos mostrar como configurar a autenticação de dois fatores (2FA) para o usuário root ao acessar o WSL, garantindo uma camada adicional de segurança. ### Objetivo Vamos configurar um script de login que valida a senha do root e usa autenticação 2FA baseada em Time-based One-Time Password (TOTP), usando ferramentas comuns como `openssl`, `oathtool`, e `perl`. ### Passo 1: Instalar as Ferramentas Necessárias Primeiro, precisamos garantir que temos todas as ferramentas necessárias instaladas. Isso inclui `openssl`, `oathtool`, e `perl`. ```bash sudo apt-get update sudo apt-get install openssl oathtool perl ``` Para os scripts em Lua.

Protheus :: Autenticação WebService versão 2.0

Dando continuidade ao tema sobre validação de acesso aos métodos do WebService do Protheus, iniciado no "post": Protheus :: Autenticação nos WebServices Protheus. Usando MD5 (Message Digest Algorithm 5) , vou publicar, nesse novo "post", a versão 2.0 do programa ali originalmente publicado. Essas alterações foram necessárias porque minha querida amiga Carla Soneta ( que solicitou o exemplo ) alertou-me sobre possíveis falhas no método anterior, uma vez que qualquer pessoa que tivesse acesso aos métodos de validação e que de alguma forma conseguisse capturar o usuário e senha poderia fazer uso indevido dos métodos ali publicados. Sendo assim, e sem querer encerrar o assunto ( pois existem n maneiras de autenticar um WebService ), vou descrever, em breves palavras, as alterações e melhorias implementadas nessa nova versão.

Essa nova versão, em relação à anterior, traz as seguintes alterações:

1 ) Na anterior o usuário e senha estavam fixos no programa. Nessa versão existe um arquivo de configuração onde vários usuários e várias senhas deverão ser configurados para acesso ao WS. Para que isso fosse possível implementamos o Conceito de "CheckSum". Nesse modelo qualquer senha definida no arquivo de configuração de usuário e senhas poderá ser usada para qualquer usuário e vice-versa. Bastando informar, junto com o usuário e a senha, o "CheckSum" dessa combinação. Mas como isso funciona? Funciona da seguinte forma: O WS de validação de usuário irá procurar no arquivo u_wsuservalid.ini as configurações de usuários e senhas, as senhas não estão diretamente associadas a um determinado usuário, vale para qualquer um. Para que essa verificação seja aceita pelo WS de autenticação, será necessário informar uma combinação numérica que relacione o usuário à senha. por exemplo:

No arquivo de configuração ( u_wsuservalid.ini ) poderemos ter as seguintes informações:

[UserName]
naldodj
Carla
NaldoDj
Soneta
NALDODJ
Carla Soneta
NaldoDJ
CarlaSoneta
NALDOdj
SonetaCarla
NAlDoDj
CarlaS
ODLANJD
SCarla
OdlanJD
SonetaC
odlanjd
CSoneta
OdlanJd
Naldo&Soneta

[UserPassWord]
b3d28e7f822dac10b74101712651597ba152c2fc
Ly9QYXJhIG8gRGVjb2RlNjQgdXNlOiBodHRwOi8vd3d3Lm9waW5pb25hdGVkZ2Vlay5jb20vZG90bmV0L3Rvb2xzL2Jhc2U2NGRlY29kZS8qLw==
9dd867e76e02c3fa10ae50dcc11081c5d2adec57
6148ea40e060b81e0baa6927adffa3b847e8bf38
9dd867e76e02c3fa10ae50dcc11081c5d2adec57
d5582b0680b92e1e5cf378d62d559e196e4a28a2
e17f619c2c04dbc833c700283f094c29
941006ed741ab68bebccfa32885cf013
OTQxMDA2ZWQ3NDFhYjY4YmViY2NmYTMyODg1Y2YwMTM=
IjlkZDg2N2U3NmUwMmMzZmExMGFlNTBkY2MxMTA4MWM1ZDJhZGVjNTci
Ikx5OVFZWEpoSUc4Z1JHVmpiMlJsTmpRZ2RYTmxPaUJvZEhSd09pOHZkM2QzTG05d2FXNXBiMjVoZEdWa1oyVmxheTVqYjIwdlpHOTBibVYwTDNSdmIyeHpMMkpoYzJVMk5HUmxZMjlrWlM4cUx3PT0i
SWt4NU9WRlpXRXBvU1VjNFoxSkhWbXBpTWxKc1RtcFJaMlJZVG14UGFVSnZaRWhTZDA5cE9IWmtNMlF6VEcwNWQyRlhOWEJpTWpWb1pFZFdhMW95Vm14aGVUVnFZakl3ZGxwSE9UQmliVll3VEROU2RtSXllSHBNTWtwb1l6SlZNazVIVW14Wk1qbHJXbE00Y1V4M1BUMGk=
726537f8c72cd9d7cfc5119ce4e5cffc
ba21af37a12b7dc83a5757db430a62ef
QWJvdXQgbWQ1IGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5jdGlvbjo=
9bf60941217f0a2f373ef0019dbfe1ea
ebaafb90de2dfce92005eb20c906437a
ZWJhYWZiOTBkZTJkZmNlOTIwMDVlYjIwYzkwNjQzN2E=
RnJvbSBXaWtpcGVkaWEsIHRoZSBmcmVlIGVuY3ljbG9wZWRpYQ==
Um5KdmJTQlhhV3RwY0dWa2FXRXNJSFJvWlNCbWNtVmxJR1Z1WTNsamJHOXdaV1JwWVE9PQ==

[TimeOut]
1300

Onde:

[UserName] define todos os usuários possíveis para acesso ao WS
[UserPassWord] define todas as senhas possíveis para acesso ao WS
[TimeOut] define o tempo, em segundos, para a validade de uma mensagem obtida através do método GetMessages.

Ex.:

Vamos supor que para a validação do WS foi selecionado o usuário "Naldo&Soneta", observe que na ordem, esse usuário possui o valor 20. E, para a senha, a escolha foi: d5582b0680b92e1e5cf378d62d559e196e4a28a2, que, se observarmos a ordem, teria o valor 6, então, o "CheckSum" para autenticar esse usuário e senha seria 20 + 6, 26. Não existe limite para a quantidade de usuários e de senhas e essa quantidade não precisa, necessariamente, ser igual. Posso ter 10 usuários para 1000 senhas como posso ter 1000 usuários para duas senhas. o "CheckSum" é que irá definir se o usuário ou senha estão ou não corretos. Para que isso fosse possível e, diferente da versão anterior, o método "ValidUserWs" do WS "u_wsUserValid", na versão 2.0 receberá, também, como parâmetro, a propriedade: "CheckSum".

Para que esses usuários e senhas sejam autenticados é necessário que o arquivo de configuração esteja na pasta "\wstoken\" abaixo do "rootpath" do "protheus". O "Client", usuário dos WS também deverá possuir esse arquivo, pois para que os usuários e senhas sejam autenticadas deverão estar nas duas pontas ( no "server" do "protheus" e no Cliente usuário do WS) . É o cliente do WS quem escolhe qual usuário e senha utilizar.

Além do conceito de múltiplos usuários e senhas e "CheckSum", foi implementado, nessa nova versão, o conceito de "TimeOut". Lembrando que para a validação do usuário e senha do WS, além do usuário, senha e, agora, "CheckSum", é necessário informar, também, o "MD5 Hash" de uma mensagem obtida através do método "GetMessage" do WS "u_wsGetMessages". Na versão anterior essa mensagem ia "crua" para o cliente e ele, após obtê-la, calculava o "MD5 Hash" e a devolvia para o método de validação. Nessa nova versão, a mensagem vai criptografada via "Base64". O Cliente solicitante da Mensagem deverá decodificá-la antes de obter o "Hash" a ser enviado para autenticação. O "TimeOut" irá definir o tempo, em segundos, que uma mensagem ,obtida através do método "GetMessage", terá validade.

O método ClearStackMD5Hash também teve um tratamento especial. Na versão anterior, qualquer um, com acesso do WS u_getmessages poderia limpar a "pilha" de mensagens, tornando a autenticação inviável. Na versão 2.0 esse método foi vinculado a um novo WS, o "u_wsClearMessages". Esse novo WS é unica e exclusivamente utilizado para limpar a "pilha de mensagens" obtidas através do método "GetMessage". A diferença básica é que agora, para limpar a "pilha" de mensagens obtidas através de "GetMessage", será necessário autenticar-se também. Ao contrário da versão anterior, o método ClearStackMD5Hash passou a receber, como parâmetro de entrada: UserWs ( Usuário ), UserWsPasswd ( Senha ) , CheckSum ( numero que relaciona o usuário à senha ), Token ( "MD5 Hash" da mensagem obtida através de "GetMessage") e HASHMD5UserAndPsw ( que definirá se deverá ser informado, no usuário e senha, os valores originais ou o "MD5 Hash" de cada um).

O WS para teste desse modelo de autenticação de WS também foi alterado de forma a contemplar as melhorias implementadas na versão 2.0. Os nomes dos programas e dos métodos são sugestivos, então acredito que vocês, caso queiram testa-los e utilizá-los, não terão problema.

Vale lembrar que:

1 ) O arquivo de configuração "u_wsuservalid.ini", que será encontrado na pasta "\wstoken\" ( abaixo do "RootPath" do Protheus), será criado na primeira vez que qualquer método dessa nova versão for executado. Ele deverá ser alterado para atender às suas necessidades.
2 ) Considerando que o programa "u_wsuservalid.prw" contém 3 WS diferentes, deverá ser gerado um "Client" para cada um deles.
3 ) No arquivo disponibilizado logo abaixo estão os "WebServices" bem como os "Clients" de cada um. Os nomes são sugestivos e poderão ser alterados a seu "bel" prazer.

Chega de enrolação e vamos ao que interessa: Clique aqui para obter a nova versão do WS para autenticação.

Carlinha, é sempre um prazer poder te ajudar. Grande abraço desse seu "amigo Malukinho". Obs.: Esse WS já está funcional, se for o seu desejo , e de seu cliente também, é só seguir o modedo implementado no WS de teste para usá-lo.

[]s

Comentários

  1. Naldo...
    tua séria de WS é muito legal. Tô acompanhando já faz um tempo. Num dos códigos vc postou a preparação do Ambiente utilizando RPCSetType(3) ou Prepare Environment.

    Ha casos em que os colegas utilizam a função ChkFile(alias) abrindo tabela a tabela.

    Qual a diferença entre as três alternativas: RPC, Prepare e ChkFile? E em termos de performance?

    []´s
    Marcelo Vicente
    marchvic@totvs.com.br

    ResponderExcluir
  2. Naldo...
    tua séria de WS é muito legal. Tô acompanhando já faz um tempo. Num dos códigos vc postou a preparação do Ambiente utilizando RPCSetType(3) ou Prepare Environment.

    Ha casos em que os colegas utilizam a função ChkFile(alias) abrindo tabela a tabela.

    Qual a diferença entre as três alternativas: RPC, Prepare e ChkFile? E em termos de performance?

    []´s
    Marcelo Vicente
    marchvic@totvs.com.br

    ResponderExcluir
  3. Existe alguma função onde pega uma imagem e converte em binário ?
    O ENCODE64 pega um texto e não uma imagem!!!

    Vlw

    ResponderExcluir

Postar um comentário

Postagens mais visitadas