(Para o propósito desta questão, suponha que eu só precise oferecer suporte ao SQL Server 2008 e superior. Ou para preparar esta questão para o futuro, digamos versões recentes, atuais e futuras próximas.)
A documentação da CREATE LOGINdeclaração diz (ênfase minha):
HASHED
Aplica-se apenas a logins do SQL Server. Especifica que a senha digitada após o argumento PASSWORD já possui hash. Se esta opção não for selecionada, a string digitada como senha é codificada antes de ser armazenada no banco de dados. Esta opção só deve ser usada para migrar bancos de dados de um servidor para outro. Não use a opção HASHED para criar novos logins. A opção HASHED não pode ser usada com hashes criados pelo SQL Server 7 ou anterior.
Não há explicação de por que essa opção não deve ser usada para criar novos logins e, se houver uma razão, não é óbvia (pelo menos para mim).
A documentação faz referência ao KB918992 , que, embora um pouco confuso, descreve as etapas que indicam que os hashes de senha herdados (2000-2008 R2) são atualizados automaticamente. Portanto, posso pegar um hash de senha gerado em 2000-2008 R2 e CREATE LOGIN ... WITH PASSWORD ... HASHEDem 2012 (+?) E converter o hash para o formato 2012 quando o principal fizer login pela primeira vez. Eu testei isso realmente funciona como descrito.
O próprio hash da senha parece ter um cabeçalho de assinatura/metadados de 6 bytes, consistindo no que eu acho que é uma tag/versão de 2 bytes e um sal de 4 bytes. Quando um hash é atualizado, a tag/versão é incrementada enquanto o salt permanece o mesmo.
A questão é então: se a Microsoft já criou esse tipo de compatibilidade futura (que presumo que precisará ser mantida daqui para frente), há alguma razão para que esse método não deva ser usado para criar novos logins?
O método de hash é presumivelmente um detalhe de implementação que pode ou não mudar em versões futuras (como já aconteceu pelo menos uma vez). Eles estão dizendo para você não fazer isso para se absolverem de quebrar seus scripts/automação se você tentar executá-los em versões mais novas ou mais antigas. É parcialmente suportado apenas para permitir a migração de logins.
Em algum ponto do processo, você teria que usar a senha de texto não criptografado para gerar a senha com hash, então não tenho certeza se você realmente ganharia muito fornecendo senhas pré-hash.
Para registro, o formato de hash do SQL Server 2012 é: 0x200<4 byte salt><hash result>
onde o resultado do hash é essencialmente:
SQL Server 2005 a 2008 R2 são idênticos, exceto que usam SHA-1 em vez de SHA-512.
Alguns motivos para NÃO usar a senha com hash anterior é que você está compartilhando salts (deixando um invasor que obtém muitas de suas senhas com menos trabalho a fazer) e você está compartilhando senhas (mais estrondo por senha quebrada para o invasor, pois isso vai direto para o dicionário de cracking) e, se um invasor crackear a versão mais fraca, ele também terá automaticamente a senha da versão mais forte (assim que executar novamente o software com as senhas quebradas anteriormente.
Idealmente, use senhas totalmente diferentes; no entanto, se nada mais, pelo menos certifique-se de que é um sal diferente em cada lugar, para que o invasor realmente tenha que se preocupar em executar a execução de crack subsequente com senhas quebradas anteriormente, em vez de simplesmente ver que o hash é idêntico, portanto, se você quebrá-lo uma vez, está feito.