De acordo com o comentário que fiz sobre a questão:
um ponto importante foi muito encoberto por quase todos ... Minha reação inicial foi muito semelhante à de Michael Brooks, até que percebi, como @stefanw, que a questão aqui é requisitos quebrados , mas estes são o que são.
Mas então, ocorreu-me que esse poderia nem ser o caso! O ponto que falta aqui é o valor tácito dos ativos do aplicativo. Em termos simples, para um sistema de baixo valor, um mecanismo de autenticação totalmente seguro, com todo o processo envolvido, seria um exagero, e o erro seria opção de segurança .
Obviamente, para um banco, as "melhores práticas" são uma obrigação e não há como violar eticamente o CWE-257. Mas é fácil pensar em sistemas de baixo valor em que simplesmente não vale a pena (mas uma senha simples ainda é necessária).
É importante lembrar que a verdadeira experiência em segurança consiste em encontrar trocas apropriadas, NÃO em divulgar dogmaticamente 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 for de valor baixo e sem ativos "caros" (a própria identidade, incluída), E existem requisitos comerciais válidos que tornam o processo adequado impossível (ou suficientemente difícil / caro), E o cliente está ciente de todas as advertências ...
Estou parando de dizer para não me incomodar com a criptografia, porque é muito simples / barato de implementar (mesmo considerando aceitável) gerenciamento de chaves) 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.
Então pode ser apropriado simplesmente permitir a criptografia reversível, sem a necessidade de interrupções especiais.
Como a suposição aqui é que o valor da senha roubada (mesmo agregada) é bastante baixo, qualquer uma dessas soluções pode ser válida.
Como há uma discussão animada, na verdade VÁRIAS discussões animadas, nas diferentes postagens e nos comentários separados, adicionarei alguns esclarecimentos e responderei a alguns dos pontos muito bons que foram levantados em outros lugares aqui.
Para começar, acho que está claro para todos aqui que permitir a recuperação da senha original do usuário é uma má prática e geralmente não é uma boa ideia. Isso não está de modo algum em disputa ...
Além disso, enfatizarei que em muitas situações, na MAIORIA, situações - é realmente errado, até sujo, desagradável e feio .
No entanto, o cerne da questão está em torno do princípio . Existe alguma situação em que talvez não seja necessário proibir isso e, em caso afirmativo, como fazê-lo da maneira mais correta e apropriada para a situação .
Agora, como @Thomas, @sfussenegger e poucos outros mencionados, a única maneira adequada de responder a essa pergunta, é fazer uma análise de risco completa de qualquer situação (ou hipotética), para entender o que está em jogo, quanto vale a pena proteger e quais outras atenuações estão em jogo para garantir essa proteção.
Não, NÃO é um chavão, é uma das ferramentas básicas e mais importantes para um profissional de segurança real. As melhores práticas são boas até certo ponto (geralmente como diretrizes para os inexperientes e os hacks), depois desse ponto uma análise cuidadosa de riscos assume o controle.
Sabe, é engraçado - eu sempre me considero 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 divulgar o dogma das "melhores práticas" (ou CWEs) SEM essa análise de risco importantíssima .
"Cuidado com o fanático por segurança que é rápido em aplicar tudo em seu cinto de ferramentas sem saber qual é o problema real contra o qual eles estão se defendendo. Mais segurança não significa necessariamente boa segurança".
A análise de risco e verdadeiros fanáticos por segurança apontariam para uma troca mais inteligente, baseada em valor / risco, com base em risco, perda potencial, possíveis ameaças, atenuações complementares etc. Qualquer "especialista em segurança" que não possa apontar para uma análise de risco sólida como o base para suas recomendações, ou suportam trocas lógicas, mas preferem expor dogmas e CWEs sem sequer entender como executar uma análise de risco, não são senão Security Hacks, e sua Especialização não vale o papel higiênico em que foram impressos.
De fato, é assim que obtemos o ridículo que é a segurança aeroportuária.
Mas antes de falarmos sobre as compensações apropriadas a serem feitas nesta situação, vamos dar uma olhada nos riscos aparentes (aparentes, porque não temos todas as informações básicas sobre essa situação, todos estamos com hipóteses - uma vez que a pergunta é qual hipotética situação pode haver ...)
Vamos assumir um sistema de BAIXO VALOR, mas não tão rival que seja o acesso público - o proprietário do sistema deseja impedir a representação casual, mas a segurança "alta" não é tão importante quanto a facilidade de uso. (Sim, é uma troca legítima ACEITAR o risco de que qualquer script-kiddie proficiente possa invadir o site ... Espere, o APT não está em voga agora ...?)
Por exemplo, digamos que estou organizando um site simples para uma grande reunião de família, permitindo que todos pensem sobre onde queremos ir no acampamento este ano. Estou menos preocupada com algum hacker anônimo, ou mesmo com o primo Fred, dando sugestões repetidas para voltar ao lago Wantanamanabikiliki, pois estou com a tia Erma que não consegue fazer logon quando precisa. Agora, tia Erma, sendo uma física nuclear, não é muito boa em lembrar senhas ou mesmo usando computadores ... Então, eu quero remover todo o atrito possível para ela. Mais uma vez, não estou preocupado com hacks, apenas não quero erros bobos de login errado - quero saber quem está chegando e o que eles querem.
De qualquer forma.
Então, quais são nossos principais riscos aqui, se criptografamos simetricamente senhas, em vez de usar um hash unidirecional?
- Representando usuários? Não, eu já aceitei esse risco, não é interessante.
- Administrador do mal? Bem, talvez ... Mas, novamente, 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 mal-intencionado receberá sua senha, não importa o quê - se o seu administrador estiver mal, seu jogo terminará de qualquer maneira.
- Outra questão que foi levantada é que a identidade é realmente compartilhada entre vários sistemas. Ah! Esse é um risco muito interessante, que requer uma análise mais detalhada.
Deixe-me começar afirmando que não é a identidade real compartilhada, mas a prova ou a credencial de autenticação. Tudo bem, uma vez que uma senha compartilhada me permitirá efetivamente entrar em outro sistema (por exemplo, minha conta bancária ou gmail), essa é efetivamente a mesma identidade, portanto, é apenas semântica ... Exceto que 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, separado da identidade nesse sistema - mais sobre isso posteriormente).
Como tal, o ponto principal de risco aqui é que o usuário insere voluntariamente sua (mesma) senha 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 dos mísseis nucleares.
Hummm.
Alguma coisa aqui parece ruim para você?
Deveria.
Vamos começar com o fato de que proteger o sistema de mísseis nucleares não é de minha responsabilidade , estou apenas construindo um local de passeio em família frakkin (para a MINHA família). Então, de quem é a responsabilidade? Umm ... E o sistema de mísseis nucleares? Duh.
Segundo, se eu quisesse roubar a senha de alguém (alguém conhecido por usar repetidamente a mesma senha entre sites seguros e não tão seguros) - por que me incomodaria em invadir seu site? Ou lutando com sua criptografia simétrica? Meu Deus, eu posso simplesmente criar meu próprio site simples , fazer com que os usuários se inscrevam para receber NOTÍCIAS MUITO IMPORTANTES sobre o que quiserem ... Puffo 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 que você tivesse que fazer o hash das senhas deles no seu site e fazer tudo o que o TSA puder pensar, você adicionou proteção à senha deles, NÃO UM BRANCO , se eles continuarem colando promiscuamente suas senhas em todos os sites em que encontrarem. NÃO se incomode em tentar.
Em outras palavras, você não possui as senhas deles , então pare de tentar agir como você.
Então, meus queridos especialistas em segurança, como uma senhora idosa perguntava por Wendy's: "Onde está o risco?"
Mais alguns pontos, em resposta a algumas questões levantadas acima:
- A CWE não é uma lei, ou regulamento, ou mesmo um padrão. É uma coleção de pontos fracos comuns , ou seja, o inverso das "Melhores Práticas".
- A questão da identidade compartilhada é um problema real, mas incompreendido (ou deturpado) pelos opositores aqui. É uma questão de compartilhar a identidade por si só (!), NÃO de quebrar as senhas em sistemas de baixo valor. Se você estiver compartilhando uma senha entre um sistema de baixo e alto valor, o problema já está lá!
- A propósito, o ponto anterior realmente apontaria CONTRA usando OAuth e similares para ambos os sistemas de baixo valor, e os sistemas bancários de alto valor.
- Sei que foi apenas um exemplo, mas (infelizmente) os sistemas do FBI não são os mais seguros. Não é muito parecido com os servidores do blog do seu gato, mas também não ultrapassam alguns dos bancos mais seguros.
- O conhecimento dividido, ou controle duplo, das chaves de criptografia NÃO acontece apenas nas forças armadas; na verdade, o PCI-DSS agora exige isso de basicamente todos os comerciantes, portanto, não está mais tão longe do mercado (se o valor o justificar).
- Para todos aqueles que reclamam que perguntas como essas são o que faz a profissão de desenvolvedor parecer tão ruim: são respostas como essas que fazem a profissão de segurança parecer ainda pior. Novamente, é necessária a análise de risco focada nos negócios, caso contrário você se torna inútil. Além de estar errado.
- Acho que é por isso que não é uma boa ideia apenas pegar um desenvolvedor regular e deixar mais responsabilidades de segurança nele, sem treinamento para pensar de forma diferente e procurar as vantagens e desvantagens corretas. Sem ofensas, para vocês aqui, sou a favor - mas há mais treinamento 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, discuta. Jogue uma birra, se necessário.
- Explique o risco de negócios para ele. Os detalhes são bons, os números são melhores, uma demonstração ao vivo geralmente é melhor.
- SE ELE AINDA insiste, E apresenta razões comerciais válidas - é hora de você fazer uma chamada de julgamento:
Este site é de baixo ou nenhum valor? É realmente um caso de negócios válido? É bom o suficiente para você? Não há outros riscos que você possa considerar que superariam os motivos comerciais válidos? (E, claro, o cliente NÃO é um site malicioso, mas é isso mesmo).
Se assim for, apenas vá em frente. Não vale a pena o esforço, o atrito e a perda de uso (nessa situação hipotética) para implementar o processo necessário. Qualquer outra decisão (novamente, nessa situação) é uma troca ruim.
Portanto, o resultado final e uma resposta real - criptografem-no com um algoritmo simétrico simples, proteja a chave de criptografia com ACLs fortes e, de preferência, DPAPI ou similar, documente-a e faça com que o cliente (alguém com experiência suficiente para tomar essa decisão) assine isto.