online - verifypassword php




Secure hash and salt para senhas do PHP (10)

IMPORTANTE : Esta resposta foi escrita em 2008.

Desde então, o PHP nos deu php.net/manual/en/function.password-hash.php e password_verify e, desde sua introdução, eles são o método recomendado de hash e verificação de senhas.

A teoria da resposta ainda é uma boa leitura.

TL; DR

Não é

  • Não limite os caracteres que os usuários podem inserir para senhas. Apenas idiotas fazem isso.
  • Não limite o tamanho de uma senha. Se seus usuários quiserem uma frase com supercalifragilisticexpialidocious, não os impeça de usá-la.
  • Nunca armazene a senha do seu usuário em texto simples.
  • Nunca envie uma senha por e-mail ao seu usuário, exceto quando ele perdeu a senha , e você enviou uma senha temporária.
  • Nunca, jamais, registre senhas de qualquer maneira.
  • Nunca hash senhas com SHA1 ou MD5 ou mesmo SHA256! Bolachas modernas podem exceder 60 e 180 bilhões de hashes / segundo (respectivamente).
  • Não misture bcrypt e com a saída bruta de hash () , use a saída hexadecimal ou base64_encode-a. (Isso se aplica a qualquer entrada que possa ter um invasor \0 , o que pode enfraquecer seriamente a segurança.)

Dos

  • Use o scrypt quando puder; bcrypt se você não puder.
  • Use PBKDF2 se você não puder usar bcrypt ou scrypt, com hashes SHA2.
  • Redefina as senhas de todos quando o banco de dados estiver comprometido.
  • Implemente um tamanho mínimo razoável de 8 a 10 caracteres, além de exigir pelo menos uma letra maiúscula, uma letra minúscula, um número e um símbolo. Isso irá melhorar a entropia da senha, tornando mais difícil a quebra. (Veja a seção "O que faz uma boa senha?" Para algum debate.)

Por que hash senhas de qualquer maneira?

O objetivo por trás de hashing de senhas é simples: impedir o acesso mal-intencionado a contas de usuários, comprometendo o banco de dados. Portanto, o objetivo do hash de senha é deter um hacker ou cracker, custando-lhe muito tempo ou dinheiro para calcular as senhas de texto simples. E tempo / custo são os melhores impedimentos em seu arsenal.

Outro motivo que você quer um hash bom e robusto em uma conta de usuário é dar a você tempo suficiente para alterar todas as senhas no sistema. Se o seu banco de dados estiver comprometido, você precisará de tempo suficiente para, pelo menos, bloquear o sistema, se não alterar todas as senhas no banco de dados.

Jeremiah Grossman, CTO da Whitehat Security, declarou em seu blog após uma recente recuperação de senha que exigia a quebra bruta de sua proteção por senha:

Curiosamente, ao viver esse pesadelo, aprendi MUITO que não sabia sobre quebra, armazenamento e complexidade de senhas. Apreciei por que o armazenamento de senhas é muito mais importante do que a complexidade de senhas. Se você não sabe como sua senha é armazenada, tudo o que você realmente pode depender é da complexidade. Isso pode ser de conhecimento comum para profissionais de senha e criptografia, mas para o especialista médio em InfoSec ou Web Security, eu duvido muito.

(Ênfase minha)

O que faz uma boa senha de qualquer maneira?

Entropy . (Não que eu assine totalmente o ponto de vista de Randall.)

Em suma, a entropia é quanto a variação está dentro da senha. Quando uma senha é apenas letras romanas minúsculas, são apenas 26 caracteres. Isso não é muita variação. Senhas alfanuméricas são melhores, com 36 caracteres. Mas permitir maiúsculas e minúsculas, com símbolos, é de aproximadamente 96 caracteres. Isso é muito melhor do que apenas cartas. Um problema é, para tornar nossas senhas memoráveis, inserimos padrões - o que reduz a entropia. Opa!

A entropia de senha é approximated facilmente. Usando toda a gama de caracteres ascii (aproximadamente 96 caracteres tipificáveis) produz uma entropia de 6,6 por caractere, que em 8 caracteres para uma senha ainda é muito baixa (52,679 bits de entropia) para segurança futura. Mas a boa notícia é: senhas mais longas e senhas com caracteres unicode, realmente aumentam a entropia de uma senha e dificultam a sua quebra.

Há uma discussão mais longa sobre a entropia de senha no site do Crypto StackExchange . Uma boa pesquisa no Google também irá gerar muitos resultados.

Nos comentários, conversei com @popnoodles, que apontou que impingir uma política de senha de tamanho X com X muitas letras, números, símbolos etc. pode reduzir a entropia, tornando o esquema de senhas mais previsível. Eu concordo. A aleatoriedade, o mais aleatória possível, é sempre a solução mais segura, mas menos memorável.

Até onde eu sou capaz de dizer, fazer a melhor senha do mundo é um Catch-22. Ou não é memorável, muito previsível, muito curto, muitos caracteres unicode (difíceis de digitar em um dispositivo Windows / Mobile), muito longos, etc. Nenhuma senha é realmente boa o suficiente para nossos propósitos, então devemos protegê-los como se fossem estavam em Fort Knox.

Melhores práticas

Bcrypt e scrypt são as melhores práticas atuais. scrypt será melhor que o bcrypt no tempo, mas ele não viu a adoção como um padrão pelo Linux / Unix ou por servidores da Web, e não teve revisões detalhadas de seu algoritmo postado ainda. Mas ainda assim, o futuro do algoritmo parece promissor. Se você está trabalhando com Ruby, existe uma gem scrypt que irá ajudá-lo, e o Node.js agora tem seu próprio pacote scrypt . Você pode usar o Scrypt no PHP através da extensão Scrypt ou da extensão Libsodium (ambas estão disponíveis no PECL).

Eu sugiro ler a documentação da função crypt se você quiser entender como usar o bcrypt, ou encontrar um good wrapper ou usar algo como openwall.com/phpass para uma implementação mais legada. Eu recomendo um mínimo de 12 rodadas de bcrypt, se não 15 a 18.

Eu mudei de idéia sobre o uso do bcrypt quando soube que o bcrypt usa apenas o cronograma chave do blowfish, com um mecanismo de custo variável. O último permite que você aumente o custo para forçar uma senha, aumentando a programação de chaves já caras do blowfish.

Práticas Médias

Eu quase não consigo mais imaginar essa situação. openwall.com/phpass suporta PHP 3.0.18 a 5.3, portanto, é utilizável em quase todas as instalações imagináveis ​​- e deve ser usado se você não sabe ao certo que o seu ambiente suporta bcrypt.

Mas suponha que você não possa usar bcrypt ou PHPASS. O que então?

Tente uma implementação de PDKBF2 com o número máximo de rodadas que seu ambiente / aplicativo / percepção do usuário pode tolerar. O menor número que eu recomendo é de 2500 rodadas. Além disso, certifique-se de usar hash_hmac() se estiver disponível para tornar a operação mais difícil de ser reproduzida.

Práticas Futuras

Vir em PHP 5.5 é uma biblioteca de proteção de senha completa que abstrai qualquer dificuldade de trabalhar com o bcrypt. Enquanto a maioria de nós está presa ao PHP 5.2 e 5.3 nos ambientes mais comuns, especialmente hosts compartilhados, o @ircmaxell construiu uma camada de compatibilidade para a API que é retrocompatível com o PHP 5.3.7.

Recapitulação e Isenção de Responsabilidade por Criptografia

O poder computacional necessário para realmente quebrar uma senha com hash não existe. A única maneira de os computadores "decifrarem" uma senha é recriá-la e simular o algoritmo de hash usado para protegê-la. A velocidade do hash está linearmente relacionada à sua capacidade de ser forçada a força bruta. Pior ainda, a maioria dos algoritmos de hash pode ser facilmente paralelizada para um desempenho ainda mais rápido. É por isso que esquemas caros como bcrypt e scrypt são tão importantes.

Você não pode prever todas as ameaças ou avenidas de ataque e, portanto, deve se esforçar ao máximo para proteger os usuários antecipadamente . Se você não o fizer, você pode até perder o fato de ter sido atacado até que seja tarde demais ... e você é responsável . Para evitar essa situação, aja paranóico para começar. Ataque seu próprio software (internamente) e tente roubar credenciais de usuário, ou modificar contas de outros usuários ou acessar seus dados. Se você não testar a segurança do seu sistema, não poderá culpar ninguém além de você mesmo.

Por fim: eu não sou um criptógrafo. O que quer que eu tenha dito é a minha opinião, mas acontece que acho que é baseado em bom senso e muita leitura. Lembre-se, seja o mais paranóico possível, torne as coisas mais difíceis de invadir o máximo possível e, se ainda estiver preocupado, entre em contato com um hacker ou um criptógrafo de chapéu branco para ver o que eles dizem sobre seu código / sistema.

Atualmente, é dito que o MD5 é parcialmente inseguro. Levando isso em consideração, gostaria de saber qual mecanismo usar para proteção por senha.

Esta pergunta, é "double hashing" uma senha menos segura do que apenas hashing uma vez? sugere que hashing várias vezes pode ser uma boa idéia, enquanto Como implementar proteção por senha para arquivos individuais? sugere o uso de sal.

Eu estou usando PHP. Eu quero um sistema de criptografia de senhas seguro e rápido. Hashing uma senha um milhão de vezes pode ser mais seguro, mas também mais lento. Como conseguir um bom equilíbrio entre velocidade e segurança? Além disso, eu preferiria que o resultado tivesse um número constante de caracteres.

  1. O mecanismo de hashing deve estar disponível em PHP
  2. Deve ser seguro
  3. Pode usar sal (neste caso, todos os sais são igualmente bons? Existe alguma maneira de gerar bons sais?)

Além disso, devo armazenar dois campos no banco de dados (um usando MD5 e outro usando SHA, por exemplo)? Isso tornaria mais seguro ou inseguro?

No caso de eu não estar claro o suficiente, quero saber quais funções hashing usar e como escolher um bom sal para ter um mecanismo seguro e rápido de proteção por senha.

Perguntas relacionadas que não cobrem bem a minha pergunta:

Qual é a diferença entre o SHA e o MD5 no PHP?
Criptografia Simples de Senha
Métodos seguros de armazenamento de chaves, senhas para asp.net
Como você implementaria senhas salgadas no Tomcat 5.5


A partir do PHP 5.5, o PHP tem funções simples e seguras para hashing e verificação de senhas, php.net/manual/en/function.password-hash.php e password_verify

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Quando password_hash() é usado, ele gera um sal aleatório e o inclui no hash de saída (junto com o custo e o algoritmo usados). password_verify() então lê esse hash e determina o método de salt e criptografia usado, e o verifica a senha fornecida em texto simples.

Fornecer o PASSWORD_DEFAULT instrui o PHP a usar o algoritmo de hashing padrão da versão instalada do PHP. Exatamente qual algoritmo que significa se destina a mudar ao longo do tempo em versões futuras, de modo que será sempre um dos mais fortes algoritmos disponíveis.

O aumento do custo (que é o padrão de 10) torna o hash mais difícil para a força bruta, mas também significa gerar hashes e verificar senhas contra eles, o que significa mais trabalho para a CPU do seu servidor.

Note que, mesmo que o algoritmo de hash padrão possa mudar, os hashes antigos continuarão a ser verificados, pois o algoritmo usado é armazenado no hash e o password_verify() capturado.


Eu encontrei o tópico perfeito sobre este assunto aqui: https://crackstation.net/hashing-security.htm , eu queria que você obtenha benefício com isso, aqui está o código-fonte também que forneceu a prevenção contra o ataque baseado no tempo também.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Eu estou usando o openwall.com/phpass que é uma simples classe PHP de um arquivo que pode ser implementada facilmente em quase todos os projetos PHP. Veja também O H.

Por padrão, ele usou a criptografia mais forte disponível, que é implementada no Phpass, que é bcrypt e volta para outras criptografias até o MD5 para fornecer compatibilidade com versões anteriores de frameworks como o Wordpress.

O hash retornado pode ser armazenado no banco de dados como está. O uso de amostra para gerar hash é:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Para verificar a senha, pode-se usar:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

Eu só quero salientar que o PHP 5.5 inclui uma API hash de senha que fornece um wrapper em torno de crypt() . Essa API simplifica significativamente a tarefa de hashing, verificação e rehashing de hashes de senha. O autor também lançou um pacote de compatibilidade (na forma de um único arquivo password.php que você simplesmente require usar), para aqueles que usam PHP 5.3.7 e posteriores e querem usar isso agora.

Ele suporta apenas BCRYPT por enquanto, mas ele tem o objetivo de ser facilmente estendido para incluir outras técnicas de hash de senhas e, como a técnica e o custo são armazenados como parte do hash, as alterações na técnica / custo de hash não invalidarão os hashes atuais. vai automagicamente, use a técnica correta / custo ao validar. Ele também lida com a geração de um sal "seguro" se você não definir explicitamente o seu próprio.

A API expõe quatro funções:

  • password_get_info() - retorna informações sobre o dado hash
  • password_hash() - cria um hash de senha
  • password_needs_rehash() - verifica se o hash dado corresponde às opções dadas. Útil para verificar se o hash está de acordo com seu esquema atual de técnica / custo, permitindo que você repita, se necessário
  • password_verify() - verifica se uma senha corresponde a um hash

No momento, essas funções aceitam as constantes de senha PASSWORD_BCRYPT e PASSWORD_DEFAULT, que são sinônimas no momento, a diferença sendo que PASSWORD_DEFAULT "pode ​​mudar em versões mais recentes do PHP quando algoritmos de hash mais novos e mais fortes forem suportados." Usando PASSWORD_DEFAULT e password_needs_rehash () no login (e refazendo se necessário) deve assegurar que seus hashes sejam razoavelmente resilientes a ataques de força bruta com pouco ou nenhum trabalho para você.

EDIT: Acabei de perceber que isso é mencionado brevemente na resposta de Robert K. Vou deixar essa resposta aqui, pois acho que ela fornece um pouco mais de informações sobre como ela funciona e a facilidade de uso que ela oferece para aqueles que não conhecem a segurança.


O Google diz que o SHA256 está disponível para o PHP.

Você definitivamente deveria usar um sal. Eu recomendo usar bytes aleatórios (e não se restringir a caracteres e números). Como normalmente, quanto mais você escolhe, mais seguro, mais lento ele fica. 64 bytes devem estar bem, eu acho.


SHA1 e um sal devem ser suficientes (dependendo, naturalmente, se você está codificando algo para Fort Knox ou um sistema de login para sua lista de compras) no futuro previsível. Se o SHA1 não for bom o suficiente para você, use o SHA256 .

A ideia de um sal é desequilibrar os resultados do hashing, por assim dizer. Sabe-se, por exemplo, que o MD5-hash de uma string vazia é d41d8cd98f00b204e9800998ecf8427e. Então, se alguém com memória suficiente, veria esse hash e saberia que é o hash de uma string vazia. Mas se a string for salgada (digamos, com a string " MY_PERSONAL_SALT"), o hash da "string vazia" (ie " MY_PERSONAL_SALT") se torna aeac2612626724592271634fb14d3ea6, portanto, não óbvio para backtrace. O que estou tentando dizer é que é melhor usar qualquer sal do que não. Portanto, não é muito importante saber qual sal usar.

Na verdade, existem sites que fazem exatamente isso - você pode alimentá-lo com um hash (md5) e ele cria um texto simples conhecido que gera esse hash específico. Se você tivesse acesso a um banco de dados que armazena md5-hashes simples, seria trivial inserir o hash para o administrador em tal serviço e efetuar login. Mas, se as senhas fossem salgadas, tal serviço se tornaria ineficaz.

Além disso, o hashing duplo é geralmente considerado um método ruim, porque diminui o espaço resultante. Todos os hashes populares são de comprimento fixo. Assim, você pode ter apenas valores finitos desse comprimento fixo e os resultados se tornam menos variados. Isso poderia ser considerado como outra forma de salga, mas eu não recomendaria isso.


COISAS PARA LEMBRAR

Muito tem sido dito sobre a criptografia de senha para PHP, a maioria dos quais é um conselho muito bom, mas antes mesmo de iniciar o processo de usar PHP para criptografia de senha, certifique-se de ter implementado o seguinte ou estar pronto para ser implementado.

SERVIDOR

PORTOS

Não importa quão boa seja a sua criptografia, se você não proteger adequadamente o servidor que executa o PHP e o DB, todos os seus esforços são inúteis. A maioria dos servidores funciona da mesma maneira, eles têm portas designadas para permitir que você os acesse remotamente através de ftp ou shell. Certifique-se de alterar a porta padrão da qual já está ativa a conexão remota. Ao não fazer isso, você fez com que o invasor fizesse menos uma etapa ao acessar seu sistema.

USERNAME

Por tudo o que é bom no mundo não use o nome de usuário admin, root ou algo similar. Além disso, se você estiver em um sistema baseado em unix, NÃO torne o login da conta root acessível, ele deve ser sempre apenas sudo.

SENHA

Você diz a seus usuários para fazer boas senhas para evitar ser hackeado, faça o mesmo. Qual é o ponto em passar por todo o esforço de trancar a porta da frente quando você tem o backdoor aberto.

BASE DE DADOS

SERVIDOR

O ideal é que você queira seu banco de dados e seu aplicativo em servidores separados. Isso nem sempre é possível devido ao custo, mas permite alguma segurança, pois o invasor terá que passar por duas etapas para acessar totalmente o sistema.

DO UTILIZADOR

Sempre faça com que seu aplicativo tenha sua própria conta para acessar o banco de dados e forneça apenas os privilégios necessários.

Em seguida, tenha uma conta de usuário separada para você que não esteja armazenada em nenhum lugar do servidor, nem mesmo no aplicativo.

Como sempre, NÃO faça esta raiz ou algo similar.

SENHA

Siga as mesmas diretrizes de todas as boas senhas. Também não reutilize a mesma senha em nenhuma conta SERVER ou DB no mesmo sistema.

PHP

SENHA

NUNCA NUNCA armazene uma senha em seu banco de dados, em vez disso armazene o hash e o sal exclusivo, explicarei por que mais tarde.

LAVAGEM

ONE WAY HASHING !!!!!!!, Nunca hash uma senha de uma forma que possa ser revertida, Hashes deve ser unidirecional, ou seja, você não os inverte e os compara com a senha; em vez disso, você hash a senha digitada da mesma forma e comparar os dois hashes. Isso significa que, mesmo que um invasor tenha acesso ao banco de dados, ele não sabe qual é a senha real, apenas o hash resultante. O que significa mais segurança para seus usuários no pior cenário possível.

Existem muitas boas funções de hashing lá fora ( password_hash , hash , etc ...) mas você precisa selecionar um bom algoritmo para o hash ser efetivo. (bcrypt e outros semelhantes a ele são algoritmos decentes.)

Quando a velocidade de hash é a chave, mais lenta é a resistência a ataques de força bruta.

Um dos erros mais comuns no hashing é que os hashes não são exclusivos dos usuários. Isso ocorre principalmente porque os sais não são gerados exclusivamente.

SALGA

As senhas devem sempre ser salgadas antes do hash. A salga adiciona uma string aleatória à senha, de modo que as senhas semelhantes não são as mesmas no banco de dados. No entanto, se o sal não é exclusivo para cada usuário (ou seja: você usa um sal codificado) do que você praticamente fez o seu sal inútil. Porque uma vez que um atacante descobre um sal de senha, ele tem o sal para todos eles.

Quando você criar um sal, certifique-se de que ele seja exclusivo da senha que ele está salgando e, em seguida, armazene o hash e o sal completos em seu banco de dados. O que isso fará é fazer com que um invasor tenha que quebrar cada sal e hash individualmente antes de obter acesso. Isso significa muito mais trabalho e tempo para o invasor.

USUÁRIOS CRIANDO SENHAS

Se o usuário estiver criando uma senha através do frontend, isso significa que ele deve ser enviado para o servidor. Isso abre um problema de segurança porque isso significa que a senha não criptografada está sendo enviada para o servidor e se um invasor é capaz de ouvir e acessar que toda a sua segurança em PHP é inútil. SEMPRE transmita os dados SECURELY, isso é feito através de SSL, mas esteja cansado, mesmo que o SSL não seja perfeito (a falha Heartbleed do OpenSSL é um exemplo disso).

Também faça o usuário criar uma senha segura, é simples e sempre deve ser feito, o usuário será grato por isso no final.

Finalmente, independentemente das medidas de segurança que você tomar, nada é 100% seguro, quanto mais avançada for a tecnologia a ser protegida, mais avançados serão os ataques. Porém, seguir essas etapas tornará seu site mais seguro e muito menos desejável para os invasores perseguirem.

Aqui está uma classe PHP que cria um hash e sal para uma senha facilmente

http://git.io/mSJqpw


ok no fitsy precisamos de sal sal deve ser único, então deixe gerá-lo

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

também precisamos do hash eu estou usando o sha512 é o melhor e é em php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

então agora podemos usar essas funções para gerar senha segura

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

agora precisamos salvar no banco de dados nosso valor da variável $ hash_psw e $ salt variable

e para autorizar vamos usar os mesmos passos ...

é a melhor maneira de proteger as senhas dos nossos clientes ...

Ps para os últimos 2 passos você pode usar seu próprio algoritmo ... mas tenha certeza que você pode gerar essa senha com hash no futuro quando precisar autorizar o usuário ...


No final, o hash duplo, matematicamente, não traz benefícios. Na prática, no entanto, é útil para evitar ataques baseados em tabelas de arco-íris. Em outras palavras, não é mais benéfico do que usar um sal, o que demanda muito menos tempo de processador em seu aplicativo ou em seu servidor.







protection