Enviei há certo tempo uma mensagem no fórum, a respeito de uma necessidade de desenvolver em um módulo do SEI um esquema para evitar que senhas que são usadas para acessar um Web Service (módulo eouv e módulo Protocolo Integrado precisam disso) fiquem informadas diretamente, em texto claro, no fonte ou no banco de dados.
Pensei na seguinte estratégia e queria ver se alguém acha algum furo nela:
Atualmente, a senha do Web Service do Protocolo Integrado é salva em texto claro no banco de dados. Essa senha é fornecida pela equipe do Protocolo Integrado (a senha é de 16 posições, composta por caracteres alfanuméricos e especiais). Pensamos implementar um estratégia diferente, baseada no one-time pad.
Ao instalar o módulo, o usuário deverá informar no código-fonte, em uma variável chamada chave, uma string de 16 posições, que pode conter qualquer caractere especial ou alfanumérico, denominado C. O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados.
No momento do uso do serviço Web Service, a operação inversa deverá ser feita. Faremos o ou-exclusivo de R e C, sendo que obteremos S. Usaremos S como senha para uso do Web Service.
A vantagem dessa abordagem é que, caso o SEI sofra invasão somente na máquina que hospeda o fonte, possuindo unicamente C, não será possível usar o Web Service. Caso o SEI sofra invasão somente na máquina que hospeda o banco de dados, possuindo unicamente R, não será possível usar o Web Service.
O manual deverá ser atualizado para indicar essa nova variável presente no código-fonte.
É uma boa?
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166
Deveria ser utilizado um algoritmo hash com salt para tal operação e não o OTP.
Cada chave no OTP, por definição, só pode ser utilizada uma única vez (aqui chave não quer dizer a senha da pessoa) onde cada vez que é encriptografado é utilizado uma única vez e somente naquela vez. E a chave deve ter o mesmo tamanho da mensagem a ser enviada. Pense no OTP como uma impressão de caracteres aleatórios para transmitir mensagens e a cada mensagem criptografada enviada é rasgado um pedaço do papel. O 'C' do seu exemplo no OTP é descartado.
No seu exemplo se alguém invadir os dois servidores eu tenho C e R e, por consequência, S. E não há a necessidade de permitir uma forma de descriptografar uma senha dessas.
A lista de algoritmos HASH da eping se encontra em http://eping.governoeletronico.gov.br/ mas saiba que há uma crítica crescente quanto ao SHA devido a ele ser rápido e assim permitir a criação de vários hash que possibilita a comparação para descoberta da mensagem inicial. Usando hash se alguém invadir o servidor do SEI vai obter R (a senha em hash) mas não terá como obter S. Se alguém invadir o servidor com a fonte não obtém nada que possa comprometer a senha S pois 'C' não existe.
E por favor não limite o tamanho da senha. O que vai ser armazenado vai ter um tamanho fixo conforme o resultado gerado pelo algoritmo escolhido mas não há a necessidade de ter um tamanho máximo para a senha. O tamanho mínimo deve existir por questão de segurança. Sempre que alguém me informa que o sistema tem tamanho máximo eu já fico desconfiado.
Não sei se fui claro o suficiente mas se quiser pode vir aqui para falar pessoalmente.
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira Enviado: quinta-feira, 9 de junho de 2016 12:02 Para: sei-tecnico@listas.softwarepublico.gov.br Assunto: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Prezados,
Enviei há certo tempo uma mensagem no fórum, a respeito de uma necessidade de desenvolver em um módulo do SEI um esquema para evitar que senhas que são usadas para acessar um Web Service (módulo eouv e módulo Protocolo Integrado precisam disso) fiquem informadas diretamente, em texto claro, no fonte ou no banco de dados.
Pensei na seguinte estratégia e queria ver se alguém acha algum furo nela:
Atualmente, a senha do Web Service do Protocolo Integrado é salva em texto claro no banco de dados. Essa senha é fornecida pela equipe do Protocolo Integrado (a senha é de 16 posições, composta por caracteres alfanuméricos e especiais). Pensamos implementar um estratégia diferente, baseada no one-time pad.
Ao instalar o módulo, o usuário deverá informar no código-fonte, em uma variável chamada chave, uma string de 16 posições, que pode conter qualquer caractere especial ou alfanumérico, denominado C. O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados.
No momento do uso do serviço Web Service, a operação inversa deverá ser feita. Faremos o ou-exclusivo de R e C, sendo que obteremos S. Usaremos S como senha para uso do Web Service.
A vantagem dessa abordagem é que, caso o SEI sofra invasão somente na máquina que hospeda o fonte, possuindo unicamente C, não será possível usar o Web Service. Caso o SEI sofra invasão somente na máquina que hospeda o banco de dados, possuindo unicamente R, não será possível usar o Web Service.
O manual deverá ser atualizado para indicar essa nova variável presente no código-fonte.
É uma boa?
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166
A questão é que a senha é usada automaticamente pelo sistema para logar no Web Service, via agendamento do SEI.
A solução ideal seria um certificado digital de máquina, mas, no momento, não foi feito assim, pelo menos não nos dois módulos do SEI que estive olhando. É algo paliativo, ainda.
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166 ________________________________
De: Carlos Eduardo Araujo Vieira Enviado: quinta-feira, 9 de junho de 2016 15:37 Para: Adriano Cesar de Oliveira; sei-tecnico@listas.softwarepublico.gov.br Assunto: RE: Estratégia de senha - Evitar texto em claro
Prezado Adriano,
Deveria ser utilizado um algoritmo hash com salt para tal operação e não o OTP.
Cada chave no OTP, por definição, só pode ser utilizada uma única vez (aqui chave não quer dizer a senha da pessoa) onde cada vez que é encriptografado é utilizado uma única vez e somente naquela vez. E a chave deve ter o mesmo tamanho da mensagem a ser enviada. Pense no OTP como uma impressão de caracteres aleatórios para transmitir mensagens e a cada mensagem criptografada enviada é rasgado um pedaço do papel. O 'C' do seu exemplo no OTP é descartado.
No seu exemplo se alguém invadir os dois servidores eu tenho C e R e, por consequência, S. E não há a necessidade de permitir uma forma de descriptografar uma senha dessas.
A lista de algoritmos HASH da eping se encontra em http://eping.governoeletronico.gov.br/ mas saiba que há uma crítica crescente quanto ao SHA devido a ele ser rápido e assim permitir a criação de vários hash que possibilita a comparação para descoberta da mensagem inicial. Usando hash se alguém invadir o servidor do SEI vai obter R (a senha em hash) mas não terá como obter S. Se alguém invadir o servidor com a fonte não obtém nada que possa comprometer a senha S pois 'C' não existe.
E por favor não limite o tamanho da senha. O que vai ser armazenado vai ter um tamanho fixo conforme o resultado gerado pelo algoritmo escolhido mas não há a necessidade de ter um tamanho máximo para a senha. O tamanho mínimo deve existir por questão de segurança. Sempre que alguém me informa que o sistema tem tamanho máximo eu já fico desconfiado.
Não sei se fui claro o suficiente mas se quiser pode vir aqui para falar pessoalmente.
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira Enviado: quinta-feira, 9 de junho de 2016 12:02 Para: sei-tecnico@listas.softwarepublico.gov.br Assunto: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Prezados,
Enviei há certo tempo uma mensagem no fórum, a respeito de uma necessidade de desenvolver em um módulo do SEI um esquema para evitar que senhas que são usadas para acessar um Web Service (módulo eouv e módulo Protocolo Integrado precisam disso) fiquem informadas diretamente, em texto claro, no fonte ou no banco de dados.
Pensei na seguinte estratégia e queria ver se alguém acha algum furo nela:
Atualmente, a senha do Web Service do Protocolo Integrado é salva em texto claro no banco de dados. Essa senha é fornecida pela equipe do Protocolo Integrado (a senha é de 16 posições, composta por caracteres alfanuméricos e especiais). Pensamos implementar um estratégia diferente, baseada no one-time pad.
Ao instalar o módulo, o usuário deverá informar no código-fonte, em uma variável chamada chave, uma string de 16 posições, que pode conter qualquer caractere especial ou alfanumérico, denominado C. O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados.
No momento do uso do serviço Web Service, a operação inversa deverá ser feita. Faremos o ou-exclusivo de R e C, sendo que obteremos S. Usaremos S como senha para uso do Web Service.
A vantagem dessa abordagem é que, caso o SEI sofra invasão somente na máquina que hospeda o fonte, possuindo unicamente C, não será possível usar o Web Service. Caso o SEI sofra invasão somente na máquina que hospeda o banco de dados, possuindo unicamente R, não será possível usar o Web Service.
O manual deverá ser atualizado para indicar essa nova variável presente no código-fonte.
É uma boa?
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166
"O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados."
Então essa senha S é armazenada também para o sistema logar automaticamente no WS?
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira
Enviado: quinta-feira, 9 de junho de 2016 15:45
Para: sei-tecnico@listas.softwarepublico.gov.br
Assunto: Re: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Olá Cadu,
A questão é que a senha é usada automaticamente pelo sistema para logar no Web Service, via agendamento do SEI.
A solução ideal seria um certificado digital de máquina, mas, no momento, não foi feito assim, pelo menos não nos dois módulos do SEI que estive olhando. É algo paliativo, ainda.
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166 ________________________________ De: Carlos Eduardo Araujo Vieira Enviado: quinta-feira, 9 de junho de 2016 15:37 Para: Adriano Cesar de Oliveira; sei-tecnico@listas.softwarepublico.gov.br Assunto: RE: Estratégia de senha - Evitar texto em claro
Prezado Adriano,
Deveria ser utilizado um algoritmo hash com salt para tal operação e não o OTP.
Cada chave no OTP, por definição, só pode ser utilizada uma única vez (aqui chave não quer dizer a senha da pessoa) onde cada vez que é encriptografado é utilizado uma única vez e somente naquela vez. E a chave deve ter o mesmo tamanho da mensagem a ser enviada. Pense no OTP como uma impressão de caracteres aleatórios para transmitir mensagens e a cada mensagem criptografada enviada é rasgado um pedaço do papel. O 'C' do seu exemplo no OTP é descartado.
No seu exemplo se alguém invadir os dois servidores eu tenho C e R e, por consequência, S. E não há a necessidade de permitir uma forma de descriptografar uma senha dessas.
A lista de algoritmos HASH da eping se encontra em http://eping.governoeletronico.gov.br/ mas saiba que há uma crítica crescente quanto ao SHA devido a ele ser rápido e assim permitir a criação de vários hash que possibilita a comparação para descoberta da mensagem inicial. Usando hash se alguém invadir o servidor do SEI vai obter R (a senha em hash) mas não terá como obter S. Se alguém invadir o servidor com a fonte não obtém nada que possa comprometer a senha S pois 'C' não existe.
E por favor não limite o tamanho da senha. O que vai ser armazenado vai ter um tamanho fixo conforme o resultado gerado pelo algoritmo escolhido mas não há a necessidade de ter um tamanho máximo para a senha. O tamanho mínimo deve existir por questão de segurança. Sempre que alguém me informa que o sistema tem tamanho máximo eu já fico desconfiado.
Não sei se fui claro o suficiente mas se quiser pode vir aqui para falar pessoalmente.
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira Enviado: quinta-feira, 9 de junho de 2016 12:02 Para: sei-tecnico@listas.softwarepublico.gov.br Assunto: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Prezados,
Enviei há certo tempo uma mensagem no fórum, a respeito de uma necessidade de desenvolver em um módulo do SEI um esquema para evitar que senhas que são usadas para acessar um Web Service (módulo eouv e módulo Protocolo Integrado precisam disso) fiquem informadas diretamente, em texto claro, no fonte ou no banco de dados.
Pensei na seguinte estratégia e queria ver se alguém acha algum furo nela:
Atualmente, a senha do Web Service do Protocolo Integrado é salva em texto claro no banco de dados. Essa senha é fornecida pela equipe do Protocolo Integrado (a senha é de 16 posições, composta por caracteres alfanuméricos e especiais). Pensamos implementar um estratégia diferente, baseada no one-time pad.
Ao instalar o módulo, o usuário deverá informar no código-fonte, em uma variável chamada chave, uma string de 16 posições, que pode conter qualquer caractere especial ou alfanumérico, denominado C. O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados.
No momento do uso do serviço Web Service, a operação inversa deverá ser feita. Faremos o ou-exclusivo de R e C, sendo que obteremos S. Usaremos S como senha para uso do Web Service.
A vantagem dessa abordagem é que, caso o SEI sofra invasão somente na máquina que hospeda o fonte, possuindo unicamente C, não será possível usar o Web Service. Caso o SEI sofra invasão somente na máquina que hospeda o banco de dados, possuindo unicamente R, não será possível usar o Web Service.
O manual deverá ser atualizado para indicar essa nova variável presente no código-fonte.
É uma boa?
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166
A senha é informada apenas uma vez no SEI pelo representante do órgão no Protocolo Integrado.
A partir daí, o SEI passa a usá-la para acessar o Web Service do Protocolo Integrado.
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166 ________________________________ De: Carlos Eduardo Araujo Vieira
Enviado: quinta-feira, 9 de junho de 2016 15:56
Para: Adriano Cesar de Oliveira; sei-tecnico@listas.softwarepublico.gov.br Assunto: RE: Estratégia de senha - Evitar texto em claro
Olá Adriano,
Você escreveu:
"O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados."
Então essa senha S é armazenada também para o sistema logar automaticamente no WS?
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira Enviado: quinta-feira, 9 de junho de 2016 15:45 Para: sei-tecnico@listas.softwarepublico.gov.br Assunto: Re: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Olá Cadu,
A questão é que a senha é usada automaticamente pelo sistema para logar no Web Service, via agendamento do SEI.
A solução ideal seria um certificado digital de máquina, mas, no momento, não foi feito assim, pelo menos não nos dois módulos do SEI que estive olhando. É algo paliativo, ainda.
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166 ________________________________ De: Carlos Eduardo Araujo Vieira Enviado: quinta-feira, 9 de junho de 2016 15:37 Para: Adriano Cesar de Oliveira; sei-tecnico@listas.softwarepublico.gov.br Assunto: RE: Estratégia de senha - Evitar texto em claro
Prezado Adriano,
Deveria ser utilizado um algoritmo hash com salt para tal operação e não o OTP.
Cada chave no OTP, por definição, só pode ser utilizada uma única vez (aqui chave não quer dizer a senha da pessoa) onde cada vez que é encriptografado é utilizado uma única vez e somente naquela vez. E a chave deve ter o mesmo tamanho da mensagem a ser enviada. Pense no OTP como uma impressão de caracteres aleatórios para transmitir mensagens e a cada mensagem criptografada enviada é rasgado um pedaço do papel. O 'C' do seu exemplo no OTP é descartado.
No seu exemplo se alguém invadir os dois servidores eu tenho C e R e, por consequência, S. E não há a necessidade de permitir uma forma de descriptografar uma senha dessas.
A lista de algoritmos HASH da eping se encontra em http://eping.governoeletronico.gov.br/ mas saiba que há uma crítica crescente quanto ao SHA devido a ele ser rápido e assim permitir a criação de vários hash que possibilita a comparação para descoberta da mensagem inicial. Usando hash se alguém invadir o servidor do SEI vai obter R (a senha em hash) mas não terá como obter S. Se alguém invadir o servidor com a fonte não obtém nada que possa comprometer a senha S pois 'C' não existe.
E por favor não limite o tamanho da senha. O que vai ser armazenado vai ter um tamanho fixo conforme o resultado gerado pelo algoritmo escolhido mas não há a necessidade de ter um tamanho máximo para a senha. O tamanho mínimo deve existir por questão de segurança. Sempre que alguém me informa que o sistema tem tamanho máximo eu já fico desconfiado.
Não sei se fui claro o suficiente mas se quiser pode vir aqui para falar pessoalmente.
Atenciosamente,
Carlos Vieira
________________________________ De: sei-tecnico em nome de Adriano Cesar de Oliveira Enviado: quinta-feira, 9 de junho de 2016 12:02 Para: sei-tecnico@listas.softwarepublico.gov.br Assunto: [sei-tecnico] Estratégia de senha - Evitar texto em claro
Prezados,
Enviei há certo tempo uma mensagem no fórum, a respeito de uma necessidade de desenvolver em um módulo do SEI um esquema para evitar que senhas que são usadas para acessar um Web Service (módulo eouv e módulo Protocolo Integrado precisam disso) fiquem informadas diretamente, em texto claro, no fonte ou no banco de dados.
Pensei na seguinte estratégia e queria ver se alguém acha algum furo nela:
Atualmente, a senha do Web Service do Protocolo Integrado é salva em texto claro no banco de dados. Essa senha é fornecida pela equipe do Protocolo Integrado (a senha é de 16 posições, composta por caracteres alfanuméricos e especiais). Pensamos implementar um estratégia diferente, baseada no one-time pad.
Ao instalar o módulo, o usuário deverá informar no código-fonte, em uma variável chamada chave, uma string de 16 posições, que pode conter qualquer caractere especial ou alfanumérico, denominado C. O usuário informa a senha recebida do Protocolo Integrado, de 16 posições (que pode ser qualquer caractere especial ou alfanumérico) na tela de configuração de parâmetros. Chamaremos essa senha de S. Ao confirmar essa senha na tela, deverá ser feito um ou-exclusivo de S x C, sendo denominado R. O valor de R será salvo no banco de dados.
No momento do uso do serviço Web Service, a operação inversa deverá ser feita. Faremos o ou-exclusivo de R e C, sendo que obteremos S. Usaremos S como senha para uso do Web Service.
A vantagem dessa abordagem é que, caso o SEI sofra invasão somente na máquina que hospeda o fonte, possuindo unicamente C, não será possível usar o Web Service. Caso o SEI sofra invasão somente na máquina que hospeda o banco de dados, possuindo unicamente R, não será possível usar o Web Service.
O manual deverá ser atualizado para indicar essa nova variável presente no código-fonte.
É uma boa?
Adriano César de Oliveira Analista em TI CGPRO/DELOG/SEGES/MPOG Tel: (61) - 2020 - 1166
Adriano César de Oliveira
Carlos Vieira