Como devo eticamente abordagem do usuário de armazenamento de senha de texto simples para posterior recuperação?

https://stackoverflow.com/questions/2283937

21-09-2019
|

Pergunta

Como eu continuar a construir mais e mais sites e aplicações web, eu sou frequentemente solicitado para armazenar senhas de usuário de uma forma que eles podem ser recuperados, se/quando o usuário tem um problema (ou para o e-mail do esquecimento da palavra-passe de ligação, caminhar com eles através do telefone, etc.) Quando eu posso lutar ferozmente contra esta prática, e eu faço um monte de 'extra' de programação para fazer redefinições de senha e de assistência administrativa possível sem armazenar a sua palavra-passe actual.

Quando eu não posso lutar com ele (ou não pode ganhar), então eu sempre codificar a senha de alguma forma para que ele, pelo menos, não é armazenada como texto simples no banco de dados—ainda que estou ciente de que se o meu DB fica cortado não demoraria muito para que o culpado para quebrar as senhas, para que me deixa desconfortável.

Em um mundo perfeito, a gente iria atualizar as senhas com freqüência e não duplicá-los em muitos sites diferentes—infelizmente, eu conheço MUITAS pessoas que têm o mesmo trabalho/casa/e-mail/senha do banco, e até mesmo ter dado livremente para mim quando precisam de ajuda.Eu não quero ser o responsável financeiro morte se o meu DB procedimentos de segurança falhar por algum motivo.

Moral e eticamente eu me sinto responsável por proteger o que pode ser, para alguns usuários, seus meios de subsistência, mesmo se eles estão tratando-a com muito menos respeito.Estou certo de que há muitos caminhos para a abordagem e argumentos a serem feitas para a salga de hashes e opções de codificação diferentes, mas existe um único "melhores práticas" quando você tem que guardar?Em quase todos os casos estou usando PHP e MySQL se isso faz alguma diferença na maneira de lidar com as especificidades.

Informações adicionais para Bounty

Eu quero esclarecer que eu sei que isso não é algo que você quer fazer e que na maioria dos casos, a recusa de fazê-lo é melhor.Estou, no entanto, não olhando para uma palestra sobre o mérito de tomar esta abordagem estou procurando as melhores medidas a tomar se você tomar esta abordagem.

Em uma nota abaixo eu fiz o ponto de sites voltados principalmente para os idosos, com deficiência mental, ou muito jovens pode tornar-se confuso para as pessoas quando eles são convidados a realizar um seguro de recuperação de senha de rotina.Embora possamos encontrá-lo simples e mundano nesses casos, alguns usuários necessitam da assistência extra de ter uma tecnologia de serviço de ajudá-los no sistema ou tê-lo enviado por e-mail/exibidos diretamente a eles.

Em tais sistemas, a taxa de atrito a partir destes dados demográficos poderia retardar o aplicativo se os usuários não tiveram esse nível de acesso à assistência, então, por favor, responda com tal configuração em mente.

Obrigado a Todos

Este foi um divertido questão com muito debate e gostei.No final, eu selecionei uma resposta que ambos mantém uma senha de segurança (eu não tem que manter o texto sem formatação ou recuperáveis senhas), mas também torna possível para o usuário da base de dados de eu especificado para fazer logon em um sistema sem as principais desvantagens achei normal de recuperação de senha.

Como sempre, havia cerca de 5 respostas que eu gostaria de ter marcada como correta, por diferentes razões, mas eu tinha que escolher o melhor, todo o resto ficou um +1.Obrigado a todos!

Também, obrigado a todos na Pilha comunidade que votaram para esta pergunta e/ou marcado como favorito.Eu tomo bater 100 votos como um elogio e espero que esta discussão tenha ajudado alguém com a mesma preocupação que eu tinha.

Solução

Como cerca de tomar outra abordagem ou ângulo com este problema?Perguntar por que a palavra-passe é necessária para ser em texto sem formatação:se é assim, que o usuário pode recuperar a palavra-passe e, em seguida, estritamente falando, não é realmente necessário para recuperar a senha, eles conjunto (não me lembro o que é de qualquer maneira), você precisa ser capaz de dar-lhes uma palavra-passe que pode usar.

Pense sobre isso:se o usuário precisa para recuperar a senha, é porque eles esqueceram.Caso em que uma nova senha seja tão bom quanto o antigo.Mas, um dos inconvenientes comuns de redefinição de senha mecanismos de hoje é que as senhas geradas produzido em uma operação de reposição são geralmente um monte de caracteres aleatórios, então é difícil para o usuário, basta digitar corretamente, a menos que elas copiam-n-colar.Que pode ser um problema para os menos experientes usuários de computador.

Uma forma de contornar esse problema é fornecer senhas geradas automaticamente que são mais ou mais menos de linguagem natural do texto.Enquanto linguagem natural seqüências de caracteres podem não ter a entropia que uma seqüência de caracteres aleatórios do mesmo comprimento, não há nada que diz a sua auto-gerada a senha precisa ter somente 8 (ou 10 ou 12 caracteres).Obter uma alta entropia auto-gerado senha por encadeamento de várias palavras aleatórias (deixe um espaço entre eles, assim eles ainda são reconhecíveis e typeable por qualquer um que pode ler).Seis palavras aleatórias de comprimento variável são, provavelmente, mais fácil de escrever corretamente e com confiança de 10 caracteres aleatórios, e eles podem ter uma maior entropia bem.Por exemplo, a entropia de uma senha de 10 caracteres sorteados aleatoriamente a partir de maiúsculas, minúsculas, dígitos e 10 símbolos de pontuação (de um total de 72 símbolos válidos) teria uma entropia de 61.7 bits.Usando um dicionário de 7776 palavras (como Diceware usa), que poderia ser selecionados aleatoriamente para um de seis palavra, frase, a frase teria um entropia de 77,4 bits.Ver o Diceware FAQ para obter mais informações.

uma frase de acesso com cerca de 77 bits de entropia:"admitir prosa flare tabela aguda flair"
uma senha com cerca de 74 bits de entropia:"K:&$R^tt~qkD"

Eu sei que eu prefiro escrever a frase, e com cópia-n-colar, a frase não é menos fácil de usar que a palavra-passe, por isso não há perda de lá.É claro que se o seu site (ou qualquer que seja protegido ativo é) não precisa de 77 bits de entropia para um auto-gerada a senha, gerar menos palavras (que eu tenho certeza que o seu blog gostaria de receber).

Eu compreendo os argumentos de que não são protegidas por senha ativos que realmente não têm um alto nível de valor, de modo que a violação de uma palavra-passe pode não ser o fim do mundo.Por exemplo, eu provavelmente não se importaria se 80% das palavras-passe que eu uso em vários sites, foi violado:tudo o que pode acontecer é alguém de spam ou postagem em meu nome por um tempo.Que não seria grande, mas não é como se eles estariam quebrando em minha conta bancária.No entanto, dado o fato de que muitas pessoas usam a mesma senha para sua web sites de fórum como eles fazem para suas contas bancárias (e, provavelmente, de segurança nacional de bancos de dados), eu acho que seria melhor para lidar com os de "baixo valor" senhas como não recuperáveis.

Outras dicas

Imagine que alguém encomendou um grande prédio a ser construído - um bar, digamos - e a seguinte conversa ocorre:

Arquiteto: Para um edifício desse tamanho e capacidade, você precisará de saídas aqui, aqui e aqui.
Cliente: Não, isso é muito complicado e caro de manter, não quero portas laterais ou portas traseiras.
Arquiteto: Senhor, as saídas de incêndio não são opcionais, elas são necessárias de acordo com o código de incêndio da cidade.
Cliente: Não estou pagando para você discutir. Apenas faça o que eu perguntei.

O arquiteto pergunta como construir eticamente este edifício sem saída de incêndio?

Na indústria de construção e engenharia, é mais provável que a conversa termine assim:

Arquiteto: Este edifício não pode ser construído sem saída de incêndio. Você pode ir a qualquer outro profissional licenciado e ele lhe dirá a mesma coisa. Estou saindo agora; Ligue -me de volta quando estiver pronto para cooperar.

A programação de computador pode não ser um licenciado Profissão, mas as pessoas geralmente parecem se perguntar por que nossa profissão não tem o mesmo respeito que um engenheiro civil ou mecânico - bem, não procure mais. Essas profissões, quando entregadas aos requisitos de lixo (ou totalmente perigosas), simplesmente recusam. Eles sabem que não é uma desculpa para dizer: "Bem, eu fiz o meu melhor, mas ele insistiu, e eu tenho que fazer o que ele diz". Eles poderiam perder sua licença por essa desculpa.

Não sei se você ou seus clientes fazem parte de qualquer empresa de capital aberto, mas armazenar senhas em qualquer formulário recuperável falhará que você falhe em vários tipos diferentes de auditorias de segurança. O problema não é o quão difícil seria para algum "hacker" que obteve acesso ao seu banco de dados para recuperar as senhas. A grande maioria das ameaças à segurança é interna. O que você precisa proteger é que algum funcionário descontente saindo com todas as senhas e vendendo -as ao maior lance. Usar a criptografia assimétrica e armazenar a chave privada em um banco de dados separado não faz absolutamente nada para evitar esse cenário; sempre haverá alguém com acesso ao banco de dados privado, e esse é um sério risco de segurança.

Não existe uma maneira ética ou responsável de armazenar senhas em um formulário recuperável. Período.

Você pode criptografar a senha + um sal com uma chave pública. Para os logins, verifique se o valor armazenado é igual ao valor calculado a partir da entrada do usuário + sal. Se chegar um momento, quando a senha precisar ser restaurada no texto simples, você pode descriptografar manualmente ou semi-automaticamente com a chave privada. A chave privada pode ser armazenada em outros lugares e também pode ser criptografada simetricamente (que precisará de uma interação humana para descriptografar a senha).

Eu acho que isso é realmente meio semelhante à maneira como o Agente de recuperação do Windows funciona.

As senhas são armazenadas criptografadas
As pessoas podem fazer login sem descriptografar em texto sem formatação
As senhas podem ser recuperadas para o texto simples, mas apenas com uma chave privada, que pode ser armazenada fora do sistema (em um banco de banco, se você quiser).

Não desista. A arma que você pode usar para convencer seus clientes é a não substituição. Se você pode reconstruir senhas de usuário por meio de qualquer mecanismo, você deu seus Clientes um mecanismo legal de não repudiação e podem repudiar qualquer transação que dependa dessa senha, porque não há como o fornecedor provar que não reconstruiram a senha e colocaram a transação através de si mesmas. Se as senhas forem corretamente armazenadas como digestas em vez de texto cifrado, isso é impossível, o ERGO que o cliente final executou a transação ou violou seu dever de cuidar da senha. Em ambos os casos, isso deixa a responsabilidade diretamente com ele. Eu trabalhei em casos em que isso equivaleria a centenas de milhões de dólares. Não é algo que você quer errar.

Você não pode eticamente armazenar palavras-passe de texto simples para posterior recuperação.É como simples como isso.Mesmo Jon Skeet não pode eticamente armazenar palavras-passe de texto simples para posterior recuperação.Se o seu blog pode recuperar senhas em texto simples de uma forma ou de outra, em seguida, potencialmente também um hacker que descobre uma vulnerabilidade de segurança no código.E isso não é apenas uma palavra-passe de utilizador a ser comprometida, mas todos eles.

Se seus clientes têm um problema com isso, dizer-lhes que o armazenamento de senhas recoverably é contra a lei.Aqui no reino UNIDO, de qualquer forma, a Lei de Protecção de Dados de 1998 (em particular, n.º 1, Parte II, Parágrafo 9) requer controladores de dados para usar as medidas técnicas adequadas para manter os dados pessoais seguros, tendo em conta, entre outras coisas, o dano que pode ser causado se os dados foram comprometidos -- que pode ser considerável para os usuários que compartilham senhas entre sites.Se eles ainda têm problemas tentando o fato de que é um problema, apontar-lhes alguns exemplos do mundo real, tais como este.

A maneira mais simples para permitir que os usuários para se recuperar de um início de sessão é para o e-mail um link que registra automaticamente e leva-los diretamente para uma página onde poderá escolher uma nova senha.Criar um protótipo e mostrá-lo em ação para eles.

Aqui estão alguns posts que eu escrevi sobre o assunto:

Atualização: agora estamos começando a ver ações judiciais e processos judiciais contra empresas que não segura as suas senhas de usuários corretamente.Exemplo: O LinkedIn bateu com us $5 milhões de ação judicial; Sony multado em £250,000 PlayStation dados hack.Se me lembro corretamente, o LinkedIn foi, na verdade, criptografar suas senhas de usuários, mas a criptografia que ele estava usando era muito fraco para ser eficaz.

Depois de ler esta parte:

Em uma nota abaixo, afirmei que os sites voltados para os idosos, com desafios mentais ou muito jovens podem se tornar confusos para as pessoas quando forem solicitados a realizar uma rotina de recuperação de senha segura. Embora possamos achar simples e mundano nesses casos, alguns usuários precisam da assistência extra de ter uma tecnologia de serviço para ajudá -los no sistema ou enviá -lo por e -mail/exibir diretamente para eles.

Nesses sistemas, a taxa de atrito dessas demografias poderia prejudicar o aplicativo se os usuários não tivessem esse nível de assistência de acesso; portanto, responda com essa configuração em mente.

Fiquei me perguntando se algum desses requisitos exige um sistema de senha recuperável. Por exemplo: tia Mabel liga e diz "seu programa de internet não está funcionando, não conheço minha senha". "Ok" diz o drone de atendimento ao cliente "deixe -me verificar alguns detalhes e depois vou Te dê uma nova senha. Quando você faz logon, ele perguntará se você deseja manter essa senha ou alterá -la para algo que você pode se lembrar com mais facilidade. "

Em seguida, o sistema é configurado para saber quando uma redefinição de senha aconteceu e exibe uma mensagem "Você gostaria de manter a nova senha ou escolher uma nova mensagem".

Como isso é pior para o menos que o PC-Liteate do que saber sua senha antiga? E embora o atendimento ao cliente possa se levantar, o banco de dados em si é muito mais seguro, caso seja violado.

Comente o que está ruim na minha sugestão e sugerirei uma solução que realmente faça o que você queria inicialmente.

Michael Brooks tem sido bastante vocal sobre a CWE -257 - o fato de que, seja qual for o método que você use, você (o administrador) ainda pode recuperar a senha. Então, que tal essas opções:

Criptografar a senha com de outra pessoa chave pública - Alguma autoridade externa. Dessa forma, você não pode reconstruí -lo pessoalmente, e o usuário terá que ir a essa autoridade externa e pedir para recuperar sua senha.
Criptografar a senha usando uma tecla gerada a partir de uma segunda senha. Faça isso do lado do cliente de criptografia e nunca o transmita no servidor. Em seguida, para recuperar, faça o lado do cliente de descriptografia novamente, gerando a chave de sua entrada. É certo que essa abordagem está basicamente usando uma segunda senha, mas você sempre pode dizer a eles para anotar ou usar a antiga abordagem de perguntas de segurança.

Eu acho que 1. é a melhor escolha, porque permite que você designar alguém da empresa do cliente para manter a chave privada. Certifique -se de que eles possam gerar a chave e armazená -la com instruções em um cofre etc. Você pode até adicionar segurança, elegendo apenas para criptografar e fornecer certos caracteres da senha para o terceiro interno, para que tenham que quebrar a senha para adivinhar isto. Fornecendo esses personagens ao usuário, eles provavelmente se lembrarão do que era!

Houve muita discussão das questões de segurança para o usuário em resposta a esta pergunta, mas eu gostaria de adicionar um de mencionar de benefícios.Até agora, eu não vi um legítimo benefício mencionado por ter um recuperável de senha armazenados no sistema.Considere isto:

O usuário se beneficiar de ter a sua senha seja enviada para eles?Não.Eles recebem o benefício mais de uma vez use o link de redefinição de senha, o que poderia vir a permitir-lhes escolher uma senha, eles vai lembrar.
O usuário se beneficiar de ter a sua password exibido na tela?Não, pelo mesmo motivo acima;eles deveriam escolher uma nova senha.
O usuário se beneficiar de ter uma pessoa do suporte falar a senha para o usuário?Não;novamente, se a pessoa de apoio que julgar a solicitação de sua senha como devidamente autenticado, é mais para o usuário do benefício a ser dado uma nova palavra-passe e a oportunidade de alterá-lo.Além disso, o suporte por telefone é mais caro do que o automatizado redefinições de senha, de forma que a empresa também não o benefício.

Parece que os únicos que podem se beneficiar recuperável senhas são aqueles com intenção maliciosa ou simpatizantes de pobres APIs que exigir de terceiros troca de senha (por favor, não use disse APIs nunca!).Talvez você pode ganhar o seu argumento pela verdade informando aos seus clientes que a empresa ganha nenhum benefício e só passivos por armazenar recuperável senhas.

Lendo entre as linhas de estes tipos de pedidos, você vai ver que seus clientes, provavelmente, não entendem, ou mesmo, na verdade, de cuidados sobre como as senhas são gerenciados.O que eles realmente querem é uma sistema de autenticação que não é tão difícil para seus usuários.Portanto, além de dizer-lhes como eles na verdade não querem recuperável de senhas, você deve oferecer-lhes maneiras de tornar o processo de autenticação menos doloroso, especialmente se você não precisa de pesados níveis de segurança de, digamos, um banco:

Permitir que o usuário use seu endereço de e-mail para seu nome de usuário.Eu já vi inúmeros casos onde o utilizador se esquecer seu nome de usuário, mas poucos se esqueça de seu endereço de e-mail.
Oferecemos OpenID e deixe um terceiro a pagar os custos do usuário esquecimento.
Facilidade de fora sobre as restrições de senha.Eu tenho certeza que todos nós temos sido incrivelmente irritado quando algum site não permite o seu preferido senha porque o inútil de requisitos, como "você não pode usar caracteres especiais" ou "sua senha é muito grande" ou "sua senha deve começar com uma letra." Além disso, se a facilidade de uso é uma maior preocupação do que a força da senha, você pode soltar até os que não são estúpidas requisitos, permitindo que mais curto senhas ou não exigir uma mistura de classes de personagem.Com afrouxou as restrições, os usuários serão mais propensos ao uso de uma senha que não se esqueça.
Não expiram senhas.
Permitir que o usuário a reutilização de uma palavra-passe antiga.
Permitir que o usuário escolha a sua própria redefinição de senha questão.

Mas se você, por algum motivo (e por favor, diga-nos o motivo) realmente, realmente, realmente precisa ser capaz de ter um recuperável senha, você pode proteger o usuário com potencial de comprometer suas outras contas on-line, dando-lhes um não-autenticação baseada em senha do sistema.Porque as pessoas já estão familiarizados com o nome de utilizador/palavra-passe de sistemas e eles são bem exercido solução, este seria um último recurso, mas há certamente uma abundância de alternativas criativas para senhas:

Permitir que o usuário escolha um pin numérico, de preferência não de 4 dígitos, e de preferência somente se força bruta tentativas são protegidos contra.
Que o usuário escolha uma pergunta com uma resposta curta que só eles sabem a resposta, nunca vai mudar, eles vão sempre lembrar, e que não se importa que outras pessoas a descobrir.
O utilizador terá de introduzir um nome de utilizador e, em seguida, desenhe um fácil-para-lembre-se de forma suficiente permutações para proteger contra a adivinhação (ver esta foto bacana de como o G1 faz isso para desbloquear o telefone).
Para crianças, um site da web, você pode gerar automaticamente uma difusa criatura com base no nome de usuário (uma espécie de identicon) e solicitar que o usuário dê a criatura um nome secreto.Eles podem, então, ser solicitado a digitar a criatura nome secreto para iniciar a sessão.

De acordo com o comentário que fiz sobre a pergunta:
Um ponto importante foi muito encoberto por quase todo mundo ... minha reação inicial foi muito semelhante a @michael brooks, até que eu percebi, como @stefanw, que o problema aqui é requisitos quebrados, mas são isso.
Mas então, ocorreu -me que isso pode nem ser o caso! O ponto que falta aqui é o não dito valor dos ativos do aplicativo. Simplesmente falando, para um sistema de baixo valor, um mecanismo de autenticação totalmente seguro, com todo o processo envolvido, seria um exagero, e o errado escolha de segurança.
Obviamente, para um banco, as "melhores práticas" são obrigatórias, e não há como violar eticamente a CWE-257. Mas é fácil pensar em sistemas de baixo valor, onde não vale a pena (mas uma senha simples ainda é necessária).

É importante lembrar que a verdadeira experiência em segurança é encontrar trocas apropriadas, não em dogmaticamente divulgar as "melhores práticas" que qualquer pessoa pode ler on -line.

Como tal, sugiro outra solução:
Dependendo do valor do sistema, e SOMENTE SE O sistema é adequadamente baixo, sem um ativo "caro" (a própria identidade, incluída), E Existem requisitos de negócios válidos que impossibilitam o processo adequado (ou suficientemente difícil/caro), E O cliente está ciente de todas as advertências ...
Em seguida, pode ser apropriado simplesmente permitir a criptografia reversível, sem aros especiais.
Estou parando de dizer que não me preocupa com a criptografia, porque é muito simples/barato de implementar (mesmo considerando o gerenciamento de chaves passíveis) e fornece alguma proteção (mais do que o custo de implementá -lo). Além disso, vale a pena analisar como fornecer ao usuário a senha original, seja por e -mail, exibindo na tela etc.
Como a suposição aqui é que o valor da senha roubada (mesmo em agregado) é bastante baixa, qualquer uma dessas soluções pode ser válida.

Como há uma discussão animada em andamento, na verdade várias discussões animadas, nas diferentes postagens e tópicos de comentários separados, adicionarei alguns esclarecimentos e responderei a alguns dos pontos positivos que foram levantados em outros lugares aqui.

Para começar, acho que está claro para todos aqui que permitir que a senha original do usuário seja recuperada, é uma prática ruim e geralmente não é uma boa ideia. Isso não está em disputa ...
Além disso, enfatizarei que em muitos, mais, situações - está realmente errado, mesmo sujo, desagradável e feio.

No entanto, o ponto crucial da questão está por perto o princípio, Existe alguma situação em que não seja necessário para proibir isso, e se sim, como fazê -lo no maneira mais correta apropriada para a situação.

Agora, como @thomas, @sfussenegger e poucos outros mencionados, a única maneira adequada de responder a essa pergunta é fazer um completo análise de risco De qualquer situação (ou hipotética), para entender o que está em jogo, quanto vale a pena proteger e o que outras mitigações estão em jogo para pagar essa proteção.
Não, não é uma palavra da moda, essa é uma das ferramentas básicas e mais importantes para um profissional de segurança real. As práticas recomendadas são boas até certo ponto (geralmente como diretrizes para os inexperientes e os hacks), após esse ponto, a análise de riscos atenciosos assume o controle.

Sabe, é engraçado - eu sempre me considerei um dos fanáticos por segurança, e de alguma forma estou do lado oposto dos chamados "especialistas em segurança" ... bem, a verdade é - porque sou fanático, E um especialista em segurança da vida real-não acredito em espalhar o dogma "prática de melhores" (ou CWEs) sem esse importante análise de risco.
"Cuidado com o zealot de segurança que é rápido em aplicar tudo em seu cinto de ferramentas sem saber qual é o problema real. Mais defender. Mais segurança não equivale a uma boa segurança".
A análise de risco e os verdadeiros fanáticos por segurança apontariam uma troca mais inteligente, baseada em valor/risco, com base em risco, perda potencial, ameaças possíveis, mitigações complementares etc. qualquer "especialista em segurança" que não possa apontar para uma análise de risco sólida como a análise de risco como a Base para suas recomendações, ou apoiar trocas lógicas, mas preferiria divulgar dogma e CWEs sem sequer entender como realizar uma análise de risco, não são inúmeras, mas hackers de segurança, e seus conhecimentos não valem o papel higiênico em que eles o imprimiam.

De fato, é assim que obtemos o ridículo que é a segurança do aeroporto.

Mas antes de falarmos sobre as trocas apropriadas para fazer nessa situação, vamos dar uma olhada nos riscos aparentes (aparentes, porque não temos todas as informações básicas sobre essa situação, estamos todos hipóteses - já que a pergunta é o que hipotético situação pode haver ...)
Vamos supor um sistema de baixo valor, mas não tão trival que é acesso público - o proprietário do sistema deseja impedir a representação casual, mas a segurança "alta" não é tão fundamental quanto a facilidade de uso. (Sim, é uma troca legítima aceitar o risco de que qualquer script proficiente possa hackear o site ... espere, não é adequado na moda agora ...?)
Por exemplo, digamos que estou organizando um site simples para uma grande reunião de família, permitindo que todos pensem em onde queremos ir em nossa viagem de acampamento este ano. Estou menos preocupado com um hacker anônimo, ou mesmo o primo Fred apertando sugestões repetidas para voltar ao lago Wantanamanabikiliki, pois sou sobre tia Erma não conseguir logon quando precisar. Agora, tia Erma, sendo um físico nuclear, não é muito bom em lembrar senhas ou mesmo usar computadores ... então eu quero remover todo o atrito possível para ela. Novamente, não estou preocupado com hacks, só não quero erros tolos de login errado - quero saber quem está chegando e o que eles querem.

De qualquer forma.
Então, quais são os nossos principais riscos aqui, se criptografarmos simetricamente senhas, em vez de usar um hash de mão única?

Representar usuários? Não, eu já aceitei esse risco, não é interessante.
Administrador do mal? Bem, talvez ... mas de novo, eu não me importo se alguém pode se passar por outro usuário, interno ou não ... e de qualquer maneira um administrador malicioso vai obter sua senha não importa o que - Se o seu administrador foi ruim, seu jogo acabou de qualquer maneira.
Outra questão levantada é que a identidade é realmente compartilhada entre vários sistemas. Ah! Este é um risco muito interessante, que requer uma aparência mais de perto.
Deixe -me começar afirmando que não é o real identidade isso é compartilhado, mas o prova, ou a credencial de autenticação. Ok, como uma senha compartilhada me permitirá efetivamente a entrada para outro sistema (por exemplo, minha conta bancária ou gmail), essa é efetivamente a mesma identidade, então é apenas semântica ... exceto que isso não é. A identidade é gerenciada separadamente por cada sistema, nesse cenário (embora possa haver sistemas de identificação de terceiros, como o OAuth - ainda assim, está separado da identidade nesse sistema - mais sobre isso mais tarde).
Como tal, o ponto principal de risco aqui é que o usuário inserirá sua senha (mesmo) em vários sistemas diferentes - e agora eu (o administrador) ou qualquer outro hacker do meu site terá acesso às senhas da tia Erma para o local de mísseis nucleares.

Hmmm.

Alguma coisa aqui parece desligada para você?

Deveria.

Vamos começar com o fato de que proteger o sistema de mísseis nucleares é não minha responsabilidade, Estou apenas construindo um site de saída da família Frakkin (para minha família). Então, de quem é a responsabilidade? Umm ... que tal o sistema de mísseis nucleares? Duh.
Segundo, se eu quisesse roubar a senha de alguém (alguém que é conhecido por usar repetidamente a mesma senha entre sites seguros e não tão seguros)-por que eu me incomodaria em invadir seu site? Ou lutando com sua criptografia simétrica? Goshdarnitall, eu posso apenas colocar meu próprio site simples, Peça aos usuários que se inscrevam para receber notícias muito importantes sobre o que quiserem ... POBPO Presto, eu "roubei" suas senhas.

Sim, a educação do usuário sempre volta para nos morder no Hienie, não é?
E não há nada que você possa fazer sobre isso ... mesmo se você hash suas senhas em seu site e fazer todo o resto em que a TSA pode pensar, você adicionou proteção à senha deles Nem um Whit, se eles continuarem prendendo suas senhas promíscuos em todos os sites em que esbarrar. Nem se preocupe em tentar.

Coloque de outra maneira, Você não possui suas senhas, então pare de tentar agir como você.

Então, meus queridos especialistas em segurança, como uma velha senhora costumava pedir a de Wendy: "Onde está o risco?"

Outros pontos, em resposta a algumas questões levantadas acima:

A CWE não é uma lei, ou regulamentação, ou mesmo um padrão. É uma coleção de fraquezas comuns, ou seja, o inverso das "melhores práticas".
A questão da identidade compartilhada é um problema real, mas incompreendido (ou deturpou) pelos pessimistas aqui. É uma questão de compartilhar a identidade por si só (!), Não sobre quebrar as senhas em sistemas de baixo valor. Se você está compartilhando uma senha entre um sistema de baixo valor e um alto valor, o problema já está lá!
A propósito, o ponto anterior realmente apontaria CONTRA Usando o OAuth e similares para esses dois sistemas de baixo valor e os sistemas bancários de alto valor.
Eu sei que foi apenas um exemplo, mas (infelizmente) os sistemas do FBI não são realmente os mais protegidos. Não é exatamente como os servidores do blog do seu gato, mas eles também não superam alguns dos bancos mais seguros.
O conhecimento dividido, ou controle duplo, das chaves de criptografia não acontecem apenas nas forças armadas, de fato PCI-DSS agora requer Isso basicamente de todos os comerciantes, então não é mais tão longe por aí (se o valor justificar).
Para todos aqueles que reclamam que perguntas como essas são o que faz com que a profissão de desenvolvedor pareça tão ruim: são respostas como essas, que tornam a profissão de segurança ainda pior. Novamente, a análise de risco focada nos negócios é necessária, caso contrário, você se torna inútil. Além de estar errado.
Eu acho que é por isso que não é uma boa idéia apenas pegar um desenvolvedor regular e soltar mais responsabilidades de segurança nele, sem treinar para pensar de maneira diferente e procurar as trocas corretas. Sem ofensa, para aqueles de vocês aqui, eu sou a favor - mas mais treinamento está em ordem.

Ufa. Que post longo ...
Mas para responder à sua pergunta original, @shane:

Explique ao cliente a maneira correta de fazer as coisas.
Se ele ainda insistir, explique um pouco mais, insista, argumento. Faça uma birra, se necessário.
Explique o risco comercial para ele. Os detalhes são bons, os números são melhores, uma demonstração ao vivo geralmente é a melhor.
Se ele ainda insistir e apresentar motivos comerciais válidos - é hora de você fazer uma chamada de julgamento:
Este site é baixo para não valer? É realmente um caso de negócios válido? É bom o suficiente para você? Não há outros riscos que você possa considerar, que superariam motivos comerciais válidos? (E, claro, o cliente não é um site malicioso, mas isso é duh).
Nesse caso, vá em frente. Não vale a pena o esforço, o atrito e o uso perdido (nesta situação hipotética) para implementar o processo necessário. Qualquer outra decisão (novamente, nesta situação) é uma troca ruim.

Portanto, a linha inferior e uma resposta real - criptografá -la com um algoritmo simétrico simples, protege a chave de criptografia com ACLs fortes e, de preferência, DPAPI ou similar isto.

Que tal uma casa de recuperação?

Armazene as senhas com uma criptografia forte e não habilite as redefinições.

Em vez de redefinir senhas, permita o envio de uma senha única (que deve ser alterada assim que o primeiro logon ocorre). Deixe o usuário alterar para qualquer senha que desejar (a anterior, se quiser).

Você pode "vender" isso como um mecanismo seguro para redefinir senhas.

A única maneira de permitir que um usuário recupere sua senha original é criptografá -lo com a própria chave pública do usuário. Somente esse usuário pode descriptografar sua senha.

Então as etapas seriam:

O usuário se registra no seu site (sobre o SSL, é claro) sem definir uma senha. Faça login -os automaticamente ou forneça uma senha temporária.
Você se oferece para armazenar sua chave PGP pública para recuperação de senha futura.
Eles carregam sua chave PGP pública.
Você pede que eles defina uma nova senha.
Eles enviam sua senha.
Você hash a senha usando o melhor algoritmo de hash de senha disponível (por exemplo, BCRYPT). Use isso ao validar o próximo log-in.
Você criptografa a senha com a chave pública e a armazena separadamente.

Se o usuário solicitar sua senha, você responderá com a senha criptografada (não hashed). Se o usuário não desejar recuperar sua senha no futuro (eles só poderiam redefini-la para uma gerada por serviços), as etapas 3 e 7 podem ser ignoradas.

Eu acho que a verdadeira pergunta que você deve se fazer é: 'Como posso ser melhor para convencer as pessoas?'

Eu tenho o mesmo problema. E da mesma maneira que sempre acho que alguém hackear meu sistema, não é uma questão de "se" mas de "quando".

Portanto, quando devo fazer um site que precisa armazenar informações confidenciais recuperáveis, como um cartão de crédito ou uma senha, o que faço:

criptografar com: OpenSSL_ENCRYPT(string $ dados, string $ método, string $ senha)
- Manual do PHP.
dados arg:
- as informações confidenciais (por exemplo, a senha do usuário)
- serialize se necessário, por exemplo, se a informação for uma variedade de dados como múltiplas informações confidenciais
senha arg: Use uma informação que apenas o usuário sabe como:
- a placa de carro do usuário
- número da Segurança Social
- número de telefone do usuário
- o nome da mãe usuário
- Uma string aleatória enviada por e -mail e/ou por SMS no tempo de registro
método arg:
- Escolha um método cifra, como "AES-256-CBC"
NUNCA Armazene as informações usadas no argumento "Senha" no banco de dados (ou qualquer lugar no sistema)

Quando necessário para recuperar esses dados, basta usar a função "OpenSSL_Decrypt ()" e peça ao usuário a resposta. Por exemplo: "Para receber sua senha, responda à pergunta: qual é o número do seu celular?"

PS 1: Nunca use como senha um dados armazenados no banco de dados. Se você precisar armazenar o número do celular do usuário, nunca use essas informações para codificar os dados. Sempre use uma informação que apenas o usuário conhece ou que é difícil para alguém não relativo conhecer.

PS 2: Para obter informações sobre cartão de crédito, como "Compra de um clique", o que eu faço é usar a senha de login. Essa senha é hashed no banco de dados (SHA1, MD5, etc.), mas no horário de login eu guardo a senha de texto simples na sessão ou em um cookie seguro não-persistente (ou seja, na memória). Essa senha simples nunca permanece no banco de dados, de fato, ela sempre permanece na memória, destruída no final da seção. Quando o usuário clica em "um clique em comprar", o sistema use esta senha. Se o usuário foi conectado a um serviço como Facebook, Twitter, etc., solicito a senha novamente no horário de compra (ok, não é totalmente "em clique") ou, em seguida, uso alguns dados do serviço que o usuário usou para fazer login (como o ID do Facebook).

Garantir credenciais não é uma operação binária: segura/não segura. A segurança tem tudo a ver com avaliação de riscos e é medida em um continuum. Os fanáticos por segurança odeiam pensar dessa maneira, mas a verdade feia é que nada é perfeitamente seguro. Senhas de hash com requisitos rigorosos de senha, amostras de DNA e verificações de retina são mais seguras, mas com um custo de desenvolvimento e experiência do usuário. As senhas de texto simples são muito menos seguras, mas são mais baratas de implementar (mas devem ser evitadas). No final do dia, tudo se resume a uma análise de custo/benefício de uma violação. Você implementa a segurança com base no valor dos dados que estão sendo protegidos e em seu valor de tempo.

Qual é o custo da senha de alguém sair para a natureza? Qual é o custo da representação no sistema especificado? Para os computadores do FBI, o custo pode ser enorme. Para o site de cinco páginas de Bob, o custo pode ser insignificante. Um profissional oferece opções para seus clientes e, quando se trata de segurança, estabelece as vantagens e riscos de qualquer implementação. Isso é duplamente, portanto, se o cliente solicitar algo que possa colocá -los em risco por causa de não prestar atenção aos padrões do setor. Se um cliente solicitar especificamente a criptografia bidirecional, eu garantiria que você documente suas objeções, mas isso não deve impedi-lo de implementar da melhor maneira que você conhece. No final do dia, é o dinheiro do cliente. Sim, você deve pressionar por usar hashes unidirecional, mas dizer que essa é absolutamente a única opção e qualquer outra coisa é antiética é um absurdo total.

Se você estiver armazenando senhas com criptografia bidirecional, a segurança se resume ao gerenciamento de chaves. O Windows fornece mecanismos para restringir o acesso aos certificados chaves privadas para contas administrativas e com senhas. Se você estiver hospedando em outras plataformas, precisará ver quais opções você tem disponível nelas. Como outros sugeriram, você pode usar criptografia assimétrica.

Não existe lei (nem a Lei de Proteção de Dados no Reino Unido) da qual estou ciente de que afirma especificamente que as senhas devem ser armazenadas usando hashes unidirecional. O único requisito em qualquer uma dessas leis é simplesmente que razoável As medidas são tomadas para segurança. Se o acesso ao banco de dados for restrito, até as senhas de texto simples poderão se qualificar legalmente sob essa restrição.

No entanto, isso traz à luz mais um aspecto: precedência legal. Se a precedência legal sugere que você deve usar hashes unidirecional, dado o setor em que seu sistema está sendo construído, isso é totalmente diferente. Essa é a munição que você usa para convencer seu cliente. Salvo isso, a melhor sugestão para fornecer uma avaliação de risco razoável, documente suas objeções e implemente o sistema da maneira mais segura que você pode obter os requisitos do cliente.

Faça a resposta para a pergunta de segurança do usuário como parte da chave de criptografia e não guarde a pergunta de segurança responda como texto simples (hash que isso em vez disso)

Eu implementar múltiplo fator de autenticação de sistemas para viver, então, para mim, é natural que se pense que você pode redefinir ou reconstruir a senha, enquanto estiver temporariamente usando um a menos do fator para autenticar o usuário apenas para o reset/recreação de fluxo de trabalho.Especialmente o uso dos OTPs (one-time passwords) como alguns dos fatores adicionais, reduz muito o risco se a janela de tempo é curto para a sugestão de fluxo de trabalho.Implementamos o software de OTP geradores para smartphones (que a maioria dos usuários já carregam com eles mesmos todos os dias), com grande sucesso.Antes de se queixa de um comercial plug aparecer, o que eu estou dizendo é que podemos diminuir os riscos inerentes a manutenção de senhas facilmente recuperáveis ou reconfigurável quando eles não são o único fator usado para autenticar um usuário.Eu admito que para a reutilização de senhas entre os sites cenários, a situação é ainda não é bonito, como o usuário irá insistir para ter a senha original, porque ele/ela quer abrir outros sites também, mas você pode tentar entregar reconstruídos a palavra-passe da forma mais segura possível (htpps e uma aparência discreta no html).

Desculpe, mas, desde que você tenha uma maneira de decodificar a senha deles, não há como ela ficar segura. Lute amargamente, e se você perder, Cya.

Acabei de encontrar esta discussão interessante e acalorada. O que mais me surpreendeu foi, porém, quão pouca atenção foi dada à seguinte pergunta básica:

Q1. Quais são as razões reais pelas quais o usuário insiste em ter acesso a uma senha armazenada por texto simples? Por que é de tanto valor?

As informações de que os usuários são idosos ou jovens realmente não respondem a essa pergunta. Mas como uma decisão comercial pode ser tomada sem entender a preocupação do cliente?

Agora, por que isso importa? Porque se a causa real da solicitação dos clientes for o sistema que é dolorosamente difícil de usar, talvez abordar a causa exata resolva o problema real?

Como não tenho essas informações e não posso falar com esses clientes, só posso adivinhar: é sobre usabilidade, veja acima.

Outra pergunta que vi fazer:

Q2. Se o usuário não se lembra da senha em primeiro lugar, por que a senha antiga importa?

E aqui está a resposta possível. Se você tem Cat chamado "Miaumiau" e usou o nome dela como senha, mas esqueceu que você fez, você prefere ser lembrado do que era ou melhor, sendo enviado algo como "#zy*rw (ew"?

Outro motivo possível é que o usuário considera um trabalho árduo criar uma nova senha! Portanto, ter a senha antiga enviada de volta dá a ilusão de salvá -la daquele trabalho doloroso novamente.

Estou apenas tentando entender o motivo. Mas seja qual for o motivo, é a razão que não é a causa que deve ser abordada.

Como usuário, eu quero coisas simples! Eu não quero trabalhar duro!

Se eu fizer login em um site de notícias para ler jornais, quero digitar 1111 como senha e terminar !!!

Eu sei que é inseguro, mas o que me importo com alguém obtendo acesso à minha "conta"? Sim, ele também pode ler as notícias!

O site armazena minhas informações "privadas"? A notícia que li hoje? Então é o problema do site, não meu! O site mostra informações privadas para o usuário autenticado? Então não mostre em primeiro lugar!

Isso é apenas para demonstrar a atitude do usuário em relação ao problema.

Portanto, para resumir, não sinto que seja um problema de como "armazenar" com segurança as senhas de texto simples (que sabemos que é impossível), mas como abordar os clientes em relação aos clientes.

Lidar com senhas perdidas/esquecidas:

Ninguém deve ser capaz de recuperar senhas.

Se os usuários esqueceram suas senhas, eles devem pelo menos conhecer seus nomes de usuário ou endereços de e -mail. Mediante solicitação, gere um GUID na tabela de usuários e enviou um email contendo um link que contém o GUID como um parâmetro para o endereço de email do usuário.

A página por trás do link verifica que o parâmetro GUID realmente existe (provavelmente com alguma lógica de tempo limite) e pede ao usuário uma nova senha.

Se você precisar de usuários de ajuda direta da linha direta, adicione algumas funções ao seu modelo de subsídios e permita que a função da linha direta faça login temporariamente como usuário identificado. Registre todos esses logins da linha direta. Por exemplo, o Bugzilla oferece esse recurso de representação aos administradores.

Que tal enviar a senha de texto simples após o registro, antes de criptografá -la e perdida? Já vi muitos sites fazer isso, e obter essa senha do email do usuário é mais segura do que deixá -lo no seu servidor/comp.

Se você não pode simplesmente rejeitar o requisito para armazenar senhas recuperáveis, e que isso como seu contra-argumento.

Podemos fazer senhas de maneira adequada e criar um mecanismo de redefinição para os usuários, ou podemos remover todas as informações de identificação pessoal do sistema. Você pode usar um endereço de e -mail para configurar as preferências do usuário, mas é isso. Use um cookie para obter preferências automaticamente em visitas futuras e jogue os dados fora após um período razoável.

A única opção que geralmente é ignorada com a política de senha é se uma senha é realmente necessária. Se a única coisa que sua política de senha faz é causar chamadas de atendimento ao cliente, talvez você possa se livrar dela.

Faça os usuários verdade Precisa se recuperar (por exemplo, ser informado) qual a senha que eles esqueceram foi ou eles simplesmente precisam poder entrar no sistema? Se o que eles realmente querem é uma senha para logon, por que não ter uma rotina que simplesmente altera a senha antiga (seja qual for) para uma nova senha que a pessoa de suporte pode dar à pessoa que perdeu sua senha?

Eu trabalhei com sistemas que fazem exatamente isso. A pessoa de suporte não tem como saber qual é a senha atual, mas pode redefini -la para um novo valor. É claro que todas essas redefinições devem ser registradas em algum lugar e uma boa prática seria gerar um email para o usuário dizendo que a senha foi redefinida.

Outra possibilidade é ter duas senhas simultâneas permitindo acesso a uma conta. Uma é a senha "normal" que o usuário gerencia e a outra é como uma chave de esqueleto/mestre que é conhecida apenas pela equipe de suporte e é a mesma para todos os usuários. Dessa forma, quando um usuário tem um problema, a pessoa de suporte pode fazer login na conta com a chave mestre e ajudar o usuário a alterar sua senha para qualquer coisa. Escusado será dizer que todos os logins com a chave mestre também devem ser registrados pelo sistema. Como medida extra, sempre que a chave mestre é usada, você também pode validar as credenciais de pessoas.

-Edit- Em resposta aos comentários sobre não ter uma chave mestre: concordo que é ruim, assim como acredito que é ruim permitir que alguém que não seja o usuário ter acesso à conta do usuário. Se você olhar para a pergunta, toda a premissa é que o cliente exigia um ambiente de segurança altamente comprometido.

Uma chave mestre não precisa ser tão ruim quanto parece. Eu trabalhava em uma fábrica de defesa onde eles perceberam a necessidade de o operador de computador mainframe ter "acesso especial" em certas ocasiões. Eles simplesmente colocam a senha especial em um envelope selado e a gravaram na mesa do operador. Para usar a senha (que o operador não sabia), ele teve que abrir o envelope. Em cada mudança de turno, um dos trabalhos do supervisor de turno era ver se o envelope havia sido aberto e, se for o caso, a senha alterada (por outro departamento) e a nova senha foi colocada em um novo envelope e o processo iniciado tudo mais uma vez. O operador seria questionado sobre por que ele o abriu e o incidente seria documentado para o registro.

Embora este não seja um procedimento que eu projetaria, ele funcionou e proporcionou uma excelente responsabilidade. Tudo foi registrado e revisado, além de todos os operadores tinham folgas secretas do DOD e nunca tivemos abusos.

Devido à revisão e supervisão, todos os operadores sabiam que, se eles usaram mal o privilégio de abrir o envelope, estavam sujeitos a demissão imediata e possível processo criminal.

Então, acho que a resposta real é que, se alguém quer fazer as coisas corretamente, contrata pessoas em quem eles podem confiar, faça verificações de antecedentes e exercem supervisão e responsabilidade adequadas do gerenciamento.

Mas, novamente, se o cliente desse sujeito pobre tivesse uma boa administração, eles não teriam pedido uma solução tão comprometida por segurança em primeiro lugar, agora não?

Pelo pouco que entendo sobre esse assunto, acredito que, se você estiver construindo um site com um sinal/senha, nem deverá ver a senha de texto simples no seu servidor. A senha deve ser hash e provavelmente salgada antes mesmo de deixar o cliente.

Se você nunca vir a senha de texto simples, a questão da recuperação não surge.

Além disso, recentemente (da Web) que (supostamente) alguns algoritmos como o MD5 não são mais considerados seguros. Não tenho como julgar isso sozinho, mas é algo a considerar.

Abra um banco de dados em um servidor independente e forneça uma conexão remota criptografada com cada servidor da Web que requer esse recurso.
Não precisa ser um banco de dados relacional, pode ser um sistema de arquivos com acesso FTP, usando pastas e arquivos em vez de tabelas e linhas.
Dê aos servidores da web permissões somente de gravação, se puder.

Armazene a criptografia não realizado da senha no banco de dados do site (vamos chamá-lo de "pass-a") como as pessoas normais :)
Em cada novo usuário (ou alteração de senha) Armazene uma cópia simples da senha no banco de dados remoto. Use o ID do servidor, o ID do usuário e o "Pass-A" como uma chave composta para esta senha. Você pode até usar uma criptografia bidirecional na senha para dormir melhor à noite.

Agora, para que alguém obtenha a senha e seu contexto (ID do site + ID do usuário + "pass-a"), ele precisa:

Hackear o banco de dados do site para obter um par ou pares ("pass-a", identificação de usuário).
Obtenha o ID do site de algum arquivo de configuração
Encontre e invadir o db de senhas remotas.

Você pode controlar a acessibilidade do Serviço de Recuperação de Senha (exponha -o apenas como um serviço da Web protegido, permitir apenas uma certa quantidade de recuperações de senhas por dia, fazê -lo manualmente etc.) e até cobrar extra por esse "acordo de segurança especial".
O servidor DB de recuperação de senhas está bastante oculto, pois não atende a muitas funções e pode ser melhor protegido (você pode adaptar com força as permissões, processos e serviços).

Em suma, você torna o trabalho mais difícil para o hacker. A chance de uma violação de segurança em qualquer servidor ainda é a mesma, mas dados significativos (uma correspondência e senha) serão difíceis de montar.

Outra opção que você pode não ter considerado é permitir ações por e -mail. É um pouco pesado, mas implementei isso para um cliente que precisava de usuários "fora" de seu sistema para visualizar (somente leitura) certas partes do sistema. Por exemplo:

Depois que um usuário é registrado, ele tem acesso total (como um site regular). O registro deve incluir um email.
Se os dados ou uma ação forem necessários e o usuário não se lembra de sua senha, eles ainda podem executar a ação clicando em um especial "Envie -me um email para obter permissão"Botão, ao lado do regular"enviar" botão.
A solicitação é enviada para o email com um hiperlink perguntando se deseja que a ação seja executada. Isso é semelhante a um link de e -mail de redefinição de senha, mas em vez de redefinir a senha, ela executa o ação única.
O usuário clica em "Sim" e confirma que os dados devem ser mostrados, ou a ação deve ser executada, os dados revelados etc.

Como você mencionou nos comentários, isso não funcionará se o email estiver comprometido, mas aborda o comentário do @Joachim sobre não querer redefinir a senha. Eventualmente, eles teriam que usar a redefinição de senha, mas poderiam fazer isso em um horário mais conveniente ou com a assistência de um administrador ou amigo, conforme necessário.

Uma reviravolta para esta solução seria enviar a solicitação de ação a um administrador confiável de terceiros. Isso funcionaria melhor em casos com idosos, com deficiência mental, muito jovens ou usuários confusos. É claro que isso requer um administrador confiável para essas pessoas apoiarem suas ações.

Sal e prejudique a senha do usuário normalmente. Ao registrar o usuário, permita a senha do usuário (após a salga/hash), mas também permita o que o usuário literalmente inseriu para corresponder também.

Isso permite que o usuário insira sua senha secreta, mas também permite que eles digitem a versão salgada/hashed de sua senha, e é o que alguém leria no banco de dados.

Basicamente, faça com que a senha salgada/hashed também seja uma senha de "texto simples".

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow