pwdcompare e pwdencrypt

SQL Server sem documentação de hashing de senha builtins: pwdcompare e pwdencrypt

Laurentiu [MSFT] Cristofor 31 de outubro de 2007 02:08 0
Em primeiro lugar, devo dizer que eu não sei porque elas existem de forma irregular. Eles foram em torno de um longo tempo e uma pesquisa em seus nomes, me deixa para trás as páginas de resultados. Estar em situação irregular significa que a sua aplicação possa variar ligeiramente de uma versão do SQL Server para outra, principalmente porque o formato de hash de senha pode mudar – e mudou durante os últimos três principais versões do SQL Server. Eles também poderiam desaparecer por completo em uma versão futura. Então, você não deve escrever aplicações utilizando essas funções, mas eles podem vir a calhar para consultas ad-hoc, quando você sabe que eles estão disponíveis.

Então aqui vai uma breve descrição das duas funções:

pwdencrypt: assume um valor varchar como parâmetro e retorna um valor varbin que é o SQL Server hash de senha do valor de entrada. Eu tenho visto pessoas falando sobre o uso desta função para hash senhas quando implementar a autenticação de aplicações customizadas. Não use isso! Começando com o SQL Server 2005, você pode usar no lugar a função HashBytes, para implementar qualquer esquema personalizado hash que você deseja. HashBytes oferece acesso direto a vários algoritmos de hash, então não há nenhum ponto em usar pwdencrypt. Na verdade, eu não posso chegar a qualquer necessidade útil para pwdencrypt ea única razão que eu incluí aqui é para avisá-lo contra o uso dela.

pwdcompare: recebe dois argumentos – um valor varchar que é uma senha em texto e um valor varbin que é um hash de senha do SQL Server, e retorna 1 se forem iguais e 0 se não. Há um terceiro parâmetro opcional que pode ser definido para 1 se o segundo parâmetro representa um servidor de pré-SQL Server 2000 o valor de hash de senha. Este terceiro parâmetro provavelmente será abandonado em uma futura versão do SQL Server.

pwdcompare é útil se você for um administrador à procura de contas que têm senhas fracas. Por exemplo, para consultar logins que possuem uma senha vazia, as consultas a seguir pode ser usado (um primeiro trabalho sobre SQL Server 2000 ea segunda usa o SQL Server 2005 novos catálogos):

Selecione o nome na sys.syslogins onde pwdcompare (”, senha) = 1
Selecione o nome na sys.sql_logins onde pwdcompare (”, password_hash) = 1

Obviamente, estas consultas podem ser usadas para procurar outros senhas fracas do que as vazias. Será que isto constitui uma ameaça contra a força de hashes de senha, permitindo que um TSQL ataque de força bruta? Não realmente, porque uma tal abordagem seria muito lenta – seria muito mais eficiente para tentar um ataque usando um programa compilado, e mesmo tal abordagem só teria uma boa chance de sucesso contra uma senha curta ou fraco. Assim, a função pwdcompare não faz o trabalho de um atacante mais fácil. Além de ajudar os administradores com a verificação de senhas fracas, eu não consigo pensar em um outro uso para esta função.

Tweet