Palavras que não podem ser usadas na senha: select, insert, update, delete, drop

 (id.uni-lj.si)
2 pontos por GN⁺ 2024-01-22 | 1 comentários | Compartilhar no WhatsApp

Redefinição de senha da identidade digital

  • Se você esqueceu a senha após ativar a identidade digital, pode redefini-la por esta página.
  • É necessário informar seus dados pessoais no formulário abaixo, e você precisa saber o nome de usuário.
  • O nome de usuário é semelhante a um endereço de e-mail, por exemplo jn1234@student.uni-lj.si.
  • Se você esqueceu tanto o nome de usuário quanto a senha, deve entrar em contato com o help desk da universidade.

Inserção de dados pessoais

  • São necessários dados pessoais para localizar a identidade digital no banco de dados.
  • É obrigatório informar nome, sobrenome, data de nascimento, ID de estudante e unidade acadêmica.
  • A seleção da unidade acadêmica oferece várias opções, como Academia de Belas-Artes e Design, Academia de Música, Academia de Teatro, Rádio, Cinema e Televisão, entre outras.

Definição do nome de usuário e da nova senha

  • O nome de usuário tem a aparência de um endereço de e-mail; por exemplo, o nome de usuário de John Smith é js1234@student.uni-lj.si.
  • Você deve escolher uma senha forte e que consiga lembrar, evitando senhas fáceis de adivinhar.
  • A senha deve ter no mínimo 10 caracteres, não pode incluir o nome e precisa atender a 3 dos seguintes critérios: letras maiúsculas, letras minúsculas, números, caracteres especiais (-_.+@).
  • A senha não pode conter combinações de caracteres como script, select, insert, update, delete, drop, --, ', /*, */.
  • É necessário digitar a senha duas vezes para evitar erros de digitação.

Opinião do GN⁺

  • Esta página ajuda usuários que esqueceram a senha da identidade digital a redefini-la com facilidade.
  • Regras fortes de criação de senha desempenham um papel importante na proteção das informações digitais do usuário.
  • O procedimento de entrar em contato com o help desk da universidade ao esquecer o nome de usuário e a senha oferece ao usuário um caminho para obter ajuda adicional.

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-22
Opiniões no Hacker News

  • Relato de um desenvolvedor que inseriu uma determinada string a pedido de um administrador. O site em questão não armazena senhas e fornece uma interface para gerenciamento de contas externas. Há rumores de que aplicativos legados podem ter uma validação estranha que impede login com senhas contendo certas strings, mas ele não conhece exemplos concretos.

  • Relato de alguém que, na infância, hackeou uma grande plataforma social. Aproveitou uma abordagem que simplesmente removia palavras proibidas para injetar tags HTML válidas e controlar quem visitava a página.

  • Opinião de que, em alguns casos, esse tipo de requisito pode ser uma boa ideia. Muitas pessoas escrevem código ruim e arquiteturas de sistema ruins, e faltam pessoas com capacidade, autoridade organizacional e tempo suficientes para identificar isso e forçar mudanças. Nos EUA, pode ser necessário fazer negócios por meio de sites horrivelmente mal programados. Nesse caso, talvez seja melhor assumir que a implementação pode ser terrível, como costuma acontecer, e recomendar mitigação de acordo com isso.

  • Crítica à abordagem de restringir algumas palavras-chave e torcer para que hackers não inventem algo fora disso, em vez de usar procedures armazenadas adequadas e técnicas para evitar completamente SQL injection. Não estamos mais em 2005; impedir que entrada do usuário se misture com SQL já não é ciência de foguetes. Armazenar senhas sem criptografia já era estupidez até em 2005.

  • Comentário dizendo que usaria truncate no lugar.

  • Opinião de que isso parece vir de sistemas antigos. Algumas universidades e bancos usam sistemas legados de mainframe para autenticação central e, em alguns casos, armazenam senhas em texto puro, limitadas a 8 caracteres e apenas em maiúsculas. O principal motivo para não atualizar esses sistemas é custo e complexidade.

  • Relato de um estudante de que nem todas as strings proibidas são verificadas.

  • Relato de alguém que teve de criar esse tipo de requisito no trabalho. Todos os dados deveriam ser escapados corretamente, e consultas parametrizadas deveriam ser usadas para evitar ataques de SQL injection, mas, como defesa em profundidade, qualquer coisa que parecesse SQL ou HTML deveria ser rejeitada em todos os campos.

  • Comentário confiante de que sua senha nunca seria detectada.

  • Palpite otimista de que esse requisito pode ter surgido de um WAF (firewall de aplicação web) excessivamente zeloso.