Istnieje ogromna głupota, jeśli chodzi o hasła na stronach internetowych.
- Niektóre mają przyczyny czysto techniczne (ważne czy nie, to inne pytanie, ale prawie wszystkie z nich nie są):
Twoje hasło musi składać się z czterech znaków i mieć tylko cyfry.
(Ograniczając hasło do zakresu 0001 .. 9999, możesz po prostu zapisać je jako liczbę, zwykły tekst w bazie danych)
- Inne są wyjaśnione błędnymi myślami, które sprawią, że hasła będą bezpieczniejsze :
Twoje hasło musi zaczynać się wielką literą, a kończyć cyfrą.
(W ten sposób deweloperowi lub kierownika, zakłada się, że to rzeczywiście zmusić użytkownikom wybrać bezpieczne hasło, podczas gdy reguła jako „Hasło musi zawierać min. 6 znaków i zawierać przynajmniej jedną wielką literę, małą litera i cyfra „magicznie tego nie zrobi)
- Inne wyjaśniono wreszcie faktem, że hasła są przechowywane w postaci zwykłego tekstu , i istnieją pewne niejasności co do sposobu ich przechowywania, przetwarzania lub odzyskiwania, i nie ma czasu na ich testowanie jednostkowe.
Twoje hasło zawiera nieprawidłowy znak é
.
lub,
Twoje hasło y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d
zawiera nieprawidłowe znaki. Używaj tylko znaków alfabetu łacińskiego i cyfr.
lub,
Twoje hasło nie może zawierać białych znaków.
We wszystkich trzech przypadkach deweloper miał tylko pewność, że takie hasła będą przechowywane poprawnie.
W pierwszym przypadku, co się stanie, jeśli é
zostanie %C3%A9
wysłany? A co jeśli baza danych będzie przechowywana é
niepoprawnie?
W drugim przypadku, co jeśli PHP (dlaczego PHP?) Nie radzi sobie z Unicode i robi coś strasznego po otrzymaniu takiego hasła? Co jeśli <
postać powoduje problemy? Co się stanie, jeśli &
znak zostanie zinterpretowany jako separator w adresie URL (zakładając, że z jakiegoś powodu hasło jest wysyłane przez GET zamiast POST)? Co jeśli '
zostanie zinterpretowane przez bazę danych, ponieważ, zgadnij co, nie mamy pojęcia, co to jest SQL Injection i jak tego uniknąć? A co, jeśli '
zostanie przekształcony \'
?
W trzecim przypadku, co jeśli PHP (ponownie?) Przycina białe znaki w niektórych przypadkach, a nie w innych? Co się stanie, jeśli administratorzy (którzy mają zaskakująco dostęp do haseł użytkowników w postaci zwykłego tekstu) zostaną utraceni, ponieważ widzą tylko jedną białą spację, a użytkownik ustawił trzy kolejne białe spacje ?
We wszystkich trzech przypadkach te dwuznaczności można łatwo rozwiązać za pomocą testów , zwłaszcza testów jednostkowych. Ale w ogromnej liczbie projektów w ogóle nie ma testów i nie ma czasu na testowanie (ale wciąż jest dużo czasu na debugowanie później).
Oznacza to, czy programista próbuje pomyśleć o możliwych konsekwencjach dopuszczenia spacji , znaków unicode, lub po prostu dowolnego znaku spoza ASCII 48..57 ∪ 65..90 ∪ 97..122 (cyfry, małe litery, wielkie litery) , najłatwiejszym sposobem, gdy testowanie nie jest możliwe, jest po prostu ich zabronić .
Moim zdaniem jest to jedyny powód, aby zabraniać spacji. Yannis Rizos podał kolejny powód związany z UX. Choć teoretycznie jest to prawdopodobny powód, w praktyce nie działa wcale: strony tworzone przez ludzi, którzy naprawdę dbają o UX, nie naprawiają głupich reguł haseł. Zamiast tego strony internetowe, w których spacja jest faktycznie zabroniona, są w większości tworzone przez osoby, które nigdy nie słyszały o UX . Jest to szczególnie prawdziwe, ponieważ zakazanie jakiegokolwiek znaku jest naprawdę denerwujące z punktu widzenia UX, ponieważ wszelkie ograniczenia związane z hasłem, w tym przydatne, jako minimalna liczba znaków.