Os sais padrão são seguros?

Ao instalar um wordpress novo, uma das coisas que se deve fazer é atualizar os sais no wp-config.php .

A seção parece assim

 define('AUTH_KEY', 'put your unique phrase here'); define('SECURE_AUTH_KEY', 'put your unique phrase here'); define('LOGGED_IN_KEY', 'put your unique phrase here'); define('NONCE_KEY', 'put your unique phrase here'); define('AUTH_SALT', 'put your unique phrase here'); define('SECURE_AUTH_SALT', 'put your unique phrase here'); define('LOGGED_IN_SALT', 'put your unique phrase here'); define('NONCE_SALT', 'put your unique phrase here'); 

Se o cliente mudar esses sais ou as constantes estão faltando, o WordPress irá salvar esses valores dentro do database.

Para gerar os sais, ele usa wp_generate_password(64, true, true) O código que faz isso pode ser encontrado em plugue a partir da linha 1993.

Agora, a questão é:

  • wp_generate_password é tão seguro quanto os sais gerados pelo https://api.wordpress.org/secret-key/1.1/salt/

  • Existe algum downgrade em segurança ao ter os sais no database, pois este método volta a isso.

  • Possui alguma implicação de segurança para não definir os valores e deixá-los gerados de forma aleatória no vôo para o db?

Solutions Collecting From Web of "Os sais padrão são seguros?"

  1. wp_generate_password() tão seguro quanto os sais gerados pelo https://api.wordpress.org/secret-key/1.1/salt/ ?

Esses detalhes não podem ser respondidos por razões óbvias, os internals são desconhecidos pelo público. Se pudéssemos responder a isso, então saber-se-ia que permitem a engenharia reversa do processo. Isso pode levar a uma diminuição da segurança. Note-se que alguém ainda poderia tentar estabelecer uma lista de solicitações para este Url e, em seguida, tentar fazer engenharia reversa do processo, observando as bolhas na superfície.

  1. Existe algum downgrade em segurança ao ter os sais no database, pois este método volta a isso?

Sim. Você não deseja ter detalhes de segurança / credenciais de autenticação salvos em qualquer lugar onde possa ser acessado por outros. Isso inclui:

  • Controle de versão
  • Histórico da linha de comando
  • Backups de database ou arquivos

Mantenha suas credenciais de autenticação e dados relacionados (como, por exemplo, “sal”) nos arquivos .env (veja o pacote Dotenv ), em seu recinto secreto seguro de serviços de implantação, em arquivos de configuração separados (por exemplo, arquivo de credenciais AWS) e, portanto, apenas em um localização única.

  1. Possui alguma implicação de segurança para não definir os valores e deixá-los gerados de forma aleatória no vôo para o db ?

Sim. Como as constantes de autenticação também são usadas em Cookies, você invalidaria seus usuários em sessões invalidando os Cookies dos usuários. Essas são constantes por uma razão: eles devem ficar e não mudar por solicitação.

Editar: Como o @gmazzap me apontou para isso, não estava falando sobre os valores salvos no database, mas sobre as constantes “geradas na marcha” . No caso de você salvá-lo no database, consulte o ponto 2 sobre segurança.

Para mais adições, siga o link de @Mark Kaplun e leia a resposta @gmazzap em detalhes (e upvote ambos).

Nota / lembrete adicional : sempre adicione alguns próprios caracteres pseudo randoms aos dados recuperados dos servidores da API. E nunca dê suas credenciais ou seu database fora de mãos. Você não vai acreditar no que as pessoas tendem a enviar por e-mail, salvar em usb-sticks, suas contas privadas dropbox ou em discos rígidos em laptops sem senha …

Editar: Como o @stephenharris apontou em [bate-papo], há uma postagem de blog interessante sobre esse assunto que é muito mais detalhado do que nossas respostas aqui.

Is wp_generate_password() tão seguro quanto os sais gerados pelo https https://api.wordpress.org/secret-key/1.1/salt/

Como o @kaiser disse que os detalhes internos da geração de sal da API não são conhecidos, mas – apenas – a API retorna uma string de 64 caracteres onde cada caractere é um dos mesmos 92 glifos possíveis usados ​​por wp_generate_password() .

Note-se que, se o servidor tiver PHP 7, os números inteiros randoms usados ​​para escolher um dos 92 glifos são gerados usando o PHP 7 CSPRNG e duvido que a API tenha algo mais forte que isso. Em versões anteriores do PHP, os valores randoms são fornecidos pelo mt_rand .

Considerando isso, e considerando que a força de uma senha reside muito mais no algoritmo de criptografia, em seguida, no sal usado, posso dizer que, sim, wp_generate_password é muito provável, tão seguro quanto os sais gerados pela API.

Existe algum downgrade em segurança ao ter os sais no database, pois este método volta a isso.

Por este ponto, concordo com @kaiser .

Vamos supor que alguém receba uma cópia do despejo do database, feito para um backup. Naquele db dump, eles podem ver suas senhas de usuários, mas criptografadas.

Se eles tiverem access a sais, é mais fácil cortar seu site.

Além disso, ao saber o sal utilizado, as IDs de usuário e as metades do usuário (onde os tokens da session são armazenados), é muito fácil reproduzir valores de nonce para qualquer um dos usuários, sem ter que saber a senha “descodificada”.

Claro, se um usuário mal-intencionado obter uma cópia do seu database, sua segurança está comprometida de qualquer maneira, mas ao armazenar sais no db, você facilita a vida desse usuário mal-intencionado.

Possui alguma implicação de segurança para não definir os valores e deixá-los gerados de forma aleatória no vôo para o db?

Se os sais não estiverem configurados, eles são gerados com wp_generate_password() apenas a primeira vez que o WP tenta acessá-los, então são armazenados no database e em pedidos subsequentes, eles são retirados de lá.

Como mencionado anteriormente, os sais gerados por wp_generate_password() não são ruins por si só, mas, como eles são armazenados em db, as implicações de segurança são o que se diz no ponto anterior: se alguém tiver access a uma cópia do seu db, é mais perigoso se Essa cópia db contém os sais.

No entanto, as reais implicações de segurança são quando os valores não seguros são usados ​​para os sais. De fato, se os valores fracos estiverem configurados na configuração, o WP não gerará nenhum valor, mas usará esses valores fracos … Em suma, se a escolha for entre nenhum sais na configuração e sais fracos, o primeiro certamente é melhor.

Observe que nas versões recentes do WP (não é seguro, a partir de qual versão exata), o valor padrão 'put your unique phrase here' é ignorado, então, se wp-config.php contiver esse valor para qualquer sal, o WordPress irá ignorá-lo e usar um valor gerado com wp_generate_password() que é melhor do que um valor fraco, mas pior do que um valor forte armazenado na configuração (porque armazenando sais no db …). Os valores gerados automaticamente são usados ​​mesmo no caso de o mesmo valor de sal ser utilizado durante mais de uma vez de sal.

Notas

  • Uma mudança nos sais será efetuar o logout de qualquer usuário registrado em seu site antes da alteração, incluindo os usuários que não estiverem logados no momento em que você alterou, mas que escolha a opção “lembrar-me” quando logado antes da alteração.

  • Quando o WordPress é instalado usando o “instalador” (sem a criação manual de wp-config.php ), os valores de sais são gerados tirando valores da API.

  1. Depende da aleatoriedade que pode ser alcançada em sua máquina. Não recordo os detalhes exatos, mas a API wordpress.org existe se a aleatoriedade da sua máquina não for boa o suficiente.

  2. Provavelmente não. Se alguém tiver esse tipo de access ao seu database ou código, você é um brinde em qualquer caso e obter os sais é o problema menos importante que você enfrenta.

  3. Qual seria uma razão para fazer isso? Obter esses 8 valores do database fará com que cada página seja servida um pouco mais lentamente sem adicionar nenhum valor à sua segurança.

Editar: por que a aleatoriedade (entropia) importa

primeiro, talvez este https://security.stackexchange.com/questions/61676/why-do-wordpress-installations-retrieve-the-crypto-secrets-remotely-on-installat, irá explicar melhor que eu

A questão é que os sais não devem ser adivinhados, por isso são gerados por transmissão em algum gerador de números randoms, que a maioria dos sistemas operacionais possui. Mas nem todos os geradores randoms são criados iguais e se, por exemplo, o seu gerador não toma como input alguns valores do ambiente, ele gerará a mesma seqüência de números e, para isso, qualquer pessoa que inspecionar o comportamento do sistema operacional possa dizer o primeiro 1000 números que serão gerados, use-os como sais e tenha um tempo mais fácil adivinhar sua senha.

Isto é especialmente problemático em um ambiente de hospedagem compartilhado onde todos os sites usam o mesmo gerador random, e por isso têm access à seqüência dos números gerados aleatoriamente e com base no conhecimento do sistema operacional e o algoritmo random empregado por ele pode adivinhar o próximo e números gerados anteriormente.

nota lateral: esta é a razão pela qual o smartphone e outro software pedem que você faça alguma input aleatória ao inicializar os dispositivos / software. Essa input aleatória serve como base para geração de números randoms e garante que cada dispositivo gerará uma seqüência de números diferente.

A vantagem de usar wordpress.org como seu gerador de números randoms é saber que os números gerados por ele são impossíveis de adivinhar sem access aos servidores, pois você não sabe qual algoritmo, está sendo usado, como ele foi inicializado e onde na sequência que você está atualmente.

Mas como a questão que eu ligue diz, o envio de serviços externos também é um problema de segurança. Eu acho isso para a paranóia de fronteira, pois esse tipo de avenida de ataque requer sofisticação que a maioria dos atacantes falta (no contexto de ataques a sites de wordpress) e eu não me preocuparia com a qualidade do gerador random, mas se você fizer isso, tudo que você precisa fazer é gerar os sais por si mesmo, talvez usando algum software gerador random que não esteja relacionado ao servidor e atualize o arquivo de configuração.