Kerberos - Cena III

Projetando um sistema de autenticação, um diálogo em quatro cenas

A manhã seguinte. Athena pega o Eurípedes no canto do café. Ela dá um tapinha no seu ombro enquanto ele enche o seu copo.
Os dois andam em direção da máquina do café.

AthenaTenho uma nova versão do Caronte para resolver os nossos problemas.
EurípedesSério? Que rápido.
AthenaBem, você sabe, problemas dessa natureza me fazem perder o sono.
EurípedesDeve ser o peso na consciência. Vamos repousar naquela salinha de reuniões?
AthenaPor que não?

Os dois se movem para a salinha de reuniões.
AthenaIniciarei expondo os problemas novamente: você só precisará fornecer a sua senha somente uma vez. Eu resolvi esse requisito inventando um novo serviço de rede. Ele se chama "concessionária de tickets", um serviço que edita os tickets do Caronte para o usuário que já tenha comprovado a sua identidade para o Caronte. Você pode utilizar essa concessionária de tickets se você tiver um ticket para ela, um ticket-concessor de ticket.

A concessionária de tickets é exatamente de fato uma versão do Caronte, uma vez que ele precisa acessar a base de dados do Caronte. Ele é uma parte do Caronte que permite você se autenticar com um ticket ao invés de uma senha.

De qualquer maneira, o sistema autenticador agora trabalha da seguinte maneira: você se loga na sua estação de trabalho e utiliza um programa chamado kinit para contatar o serviço Caronte. Você comprova a sua identidade para o Caronte, e o prgrama kinit pega para você um ticket-concessor de ticket.

Agora digamos que você quer pegar a sua correspondência no servidor de correio. Você ainda não tem um ticket do servidor de correio, então você usa o ticket-concessor de ticket para pegar o ticket do servidor de correio para você. Você não precisa usar a sua senha para pegar o novo ticket.
EurípedesEu preciso pegar um novo ticket-concessor de ticket toda vez que eu precisar acessar um outro serviço da rede?
AthenaNão. Lembre-se, nós concordamos da última vez que os tickets podem ser reutilizados. Uma vez que você tenha adquirido um ticket-concessor de ticket, você não precisa pegar outro. Você usa o ticket-concessor de ticket para obter os outros tickets que você necessitar.
EurípedesCerto, isso faz sentido. E desde que você possa reusar os tickets, uma vez que a concessionária de tickets te deu um ticket para um serviço específico, você não precisa pegar tickets específicos novamente.
AthenaÉ isso aí, não ficaria interessante?
EurípedesComprei a idéia faz já tempo... Contanto que você não tenha que enviar a sua senha em texto aberto na rede para pegar o ticket-concessor de ticket.
AthenaConforme eu disse, já resolvi esse problema também. A questão é, quando eu digo que você precisa contatar o Caronte para pegar o ticket-concessor de ticket, eu quis dizer que você precisa enviar a sua senha em texto aberto sobre a rede para o Servidor do Caronte. Mas isso não precisaria ser assim.

A coisa funciona assim. Quando você utiliza o programa kinit para pegar o ticket-concessor de ticket, o kinit não envia a sua senha para o servidor Caronte, o kinit envia somente o seu nome de usuário.
EurípedesLegal.
AthenaO Caronte usa o nome de usuário para localizar a sua senha. Depois o Caronte monta um pacote de dados que contém o ticket-concessor de ticket. Antes dele te enviar o pacote, o Caronte usa a sua senha para criptografar o conteúdo do pacote.

A sua estação de trabalho recebe o pacote do ticket. Você entra a sua senha, o kinit tenta descriptografar o ticket com a senha que você forneceu. Se o kinit for bem sucedido, você terá se autenticado com sucesso junto ao Caronte. Você agora possui um ticket-concessor de ticket, e esse ticket obterá os outros tickets que você requisitar.

Como isso soa mestre?
EurípedesNão sei... estou pensando. Sabe, eu acho que as partes do sistema que você descrever agora estão legais. O seu sistema solicita que eu me autentique somente uma vez. Depois disso, o Caronte pode me conceder tickets de serviço sem a minha intervenção. Sem ressalvas em relação a isso. Mas ainda tem alguma coisa no desenho do ticket de serviço que me incomoda. Tem a ver com o fato de os tickets serem reusáveis. Eu ainda concordo que eles têm que ser reusáveis, porém tickets reusáveis são, devido a sua natureza, muito perigosos.
AthenaComo assim?
EurípedesVeja o seguinte. Suponha que você esteja utilizando uma estação de trabalho insegura. Durante a sua sessão logada, você adquire um ticket de serviço de correio, um ticket de serviço de impressão e um ticket de serviço de arquivo. Suponha que inadvertidamente, você deixe esses tickets na sua estação de trabalho quando você faça o logout.

Agora suponha que eu me logue na sua estação de trabalho e localize aqueles tickets. Eu faço a sua estação de trabalho pensar que eu sou você, e desde que os tickets são confeccionados no seu nome, eu posso utilizar o programa cliente de correio para acessar a sua correspondência, eu posso utilizar o cliente do servidor de arquivos para acessar e remover os seus arquivos e posso utilizar os comandos de impressão deixando as contas para você pagar. Tudo porque esses tickets foram acidentalmente deixados por aí.

E nada pode me deter de copiar esses tickets para onde eu quiser. E posso continuar a utilizá-los eternamente.
AthenaMas é fácil corrigir isso. Só precisamos escrever um programa que destura os tickets dos usuários depois de cada sessão logada. Você não poderá utilizar tickets que tenham sido destruídos.
EurípedesBem, obviamente o seu sistema precisará de um programa destruidor de tickets, mas é besteira deixar os usuários confiarem nisso. Você não pode depender que usuários lembrem-se de destruir os seus tickets todas as vezes que eles terminarem uma sessão na estação de trabalho. E mesmo se você confiar que os seus usuários destruirão os seus tickets, considere o seguinte cenário.

Eu tenho um programa que monitora o tráfego de rede e copia os tickets de serviço enquanto eles cruzam a rede. Agora imagine eu judiando de você. Eu espero você iniciar uma sessão na sua estação de trabalho, eu rodo o meu programa e copio uma porção dos seus tickets.

Eu espero você finalizar a sua sessão até você se deslogar e sair. Eu dou um balão com o software de rede da minha estação de trabalho e altero o endereço para que ele tenha o mesmo endereço que a estação de trabalho que você estava utilizando quando você adquiriu os tickets que eu copiei. Eu faço a minha estação de trabalho acreditar que eu sou você. Eu tenho os seus tickets, os seu nome de usuário e o endereço correto do endereço da rede. Eu posso REUSAR esses tickets e utilizar serviços no seu nome.

Não importa que você distruiu os tickets antes de você finalizar a sessão na sua estação de trabalho. Os tickets que eu roubei serão válidos sempre que eu quiser usá-los, porque atualmente o seu projeto de tickets não coloca uma limitação no número de vezes para o reuso, ou por quanto tempo eles permanecem válidos.
AthenaEntendi o que você quis dizer! Tickets não podem ser válidos para sempre porque eles podem constituir um enorme risco de segurança. Nós temos que restringir a duração do tempo de uso do ticket, talvez dando a cada ticket algum tipo de data de expiração.
EurípedesExatamente. Eu acho que cada ticket precisa ter duas informações adicionais: o tempo de vida que indica a duração do tempo de validade de cada ticket, e um selo cronológico que indica a data e a hora em que o Caronte emitiu o ticket. Estão o ticket ficaria mais ou menos assim:

Eurípedes vai até a lousa e rabisca o seguinte:

TICKET {nomedeusuario:
endereço:
serviço:
tempodevida:
selocronologico}

Agora quando um serviço descriptografar os tickets, ele irá checar o usuário e o endereço do ticket contra o nome e o endereço da pessoa que enviou o ticket, e ele irá utilizar as informações de tempo de vida e o selo cronológico para verificar se o ticket expirou.
AthenaCerto. Qual o tempo de vida um serviço de ticket característico deve ter?
EurípedesNão sei. Talvez o tamanho de uma sessão típica na estação de trabalho. Digamos oito horas.
AthenaEntão se eu fico na minha estação de trabalho por mais de oito horas, todos os tickets expiram. Isso inclui o meu ticket-concessor de ticket. Então eu preciso me reautenticar no Caronte depois de oito horas.
EurípedesNão seria demais, não é?
AthenaAcho que não. Então estamos combinados, os tickets expiram depois de oito horas. Agora eu tenho uma questão para você. Suponha que eu tenha copiado os SEUS tickets da rede...
Eurípedes(Olhos cintilando). Ei Tina! Você não faria uma coisa dessas, faria?
AthenaÉ só um exemplo. Eu copiei os seus tickets. Agora eu espero você se deslogar. Suponha que você tenha uma consulta médica uma uma aula para ministrar, então você finaliza a sessão na sua estação de trabalho depois de algumas horas. Você é um cara esperto e destruiu as cópias dos seus tickets antes de se deslogar.

Mas eu roubei os seus tickets e eles possuem seis horas de vida. O que me dá um grande intervalo de tempo para pilhar os seus arquivos e imprimir milhares de cópias no seu nome.

Veja, esse negócio de tempo de vida e selo cronológico funcionam bem no caso de um ladrão tentar reusar o ticket depois que ele tenha expirado. Se o ladrão puder reusar o ticket antes disso...
EurípedesUhn... Claro, você está certa.
AthenaAcho que estamos frente à um grande problema (ela suspira)

Pause
EurípedesAcho que isso significa que você vai ter uma noite daquelas. Quer mais café?
AthenaPorque não?




------------------
Cena IV


---------------------
Revisões
Traduzido em 04/10/2007 14:20 em aprox. 2:30 hr
Editado e publicado em 09/10/2007 19:30 em aproximadamente 1:45 hr

Popular posts from this blog

Atom - Jupyter / Hydrogen

Image
I will show you how to use the Atom editor with Jupyter Notebook to debug Python/Django views using Hydrogen plugin. On the Internet you can find some examples using this setup to debug Python but I found nothing related to Django, so I decided to publish this notes. This is not a high performance setup, because it involves many technologies at several layers. This is more a proof of concept of nowadays technologies which are available to the programmer's toolbox. This notes has been written during the development and improvement of the automated tests of the Virtual Library of FAPESP ( http://www.bv.fapesp.br ). The environment The diagram below shows an actual infrastructure to use this setup in a development environment. Technologies It is not expected that you know all of the technologies in detail, but there are some trick points. This paper is oriented for Python programmer who already use Atom and Jupyter and enjoy explore the edges of these tools. ...
Read more

Metodologias em ação

Image
O objetivo desse artigo é apresentar algumas metodologias atuais relacionadas à TI, na perspectiva das suas aplicações dentro de uma empresa. A estrutura de cada empresa pode variar muito, dessa maneira irei adotar uma estrutura clássica em formato de pirâmide, representada na figura abaixo para efeitos da nossa análise. As metodologias apresentadas, dificilmente serão utilizadas exatamente como estão sendo estudadas aqui pois não é comum a necessidade de utilizá-las em uma empresa todas ao mesmo tempo, apesar de ser possível. Isso dependerá do tipo de empresa, da estrutura que a mesma possui e como a empresa aplica a TI nos seus negócios. Também será feita uma breve análise do relacionamento entre as diversas metodologias quando adotadas em conjunto. A pirâmide representa a hierarquia em uma empresa tradicional, com o board of directors ficando no topo, abaixo a gerência senior com os CEO, CIO, CSO, CFO etc, abaixo a gerência operacional e abaixo os departamentos operacionais. Qual o ...
Read more

Design Patterns - Observer

Design Patterns - Observer A simple Python code example to illustrate the Observer Pattern for an ETL-like scenario. The "Extract Microservice" observes changes in a data source and notifies its registered observers (data extractors) to perform data extraction. We'll use a basic Publisher-Subscriber pattern to demonstrate the concept of the Observer Pattern. Observer interface class Observer: def update(self, data): pass Extract Microservice (Subject) class ExtractMicroservice: def __init__(self): self.observers = [] def register_observer(self, observer): self.observers.append(observer) def unregister_observer(self, observer): self.observers.remove(observer) def notify_observers(self, data): for observer in self.observers: observer.update(data) def start_extraction(self): # Simulate data extraction process data = ["Data 1", "Data 2", "Data 3",...
Read more