Co do iTVP — ja mam taką swoją teorię, że większość zepsutych serwisów (chodzi mi o usability) cierpi na ten problem, że nie korzystają z nich ich autorzy. Krzesło może ładnie wyglądać, ale dopóki nie siądziesz, to nie poczujesz, jak innych dupa boli.

I tyle.

Być może jest jakiś przesąd? Coś typu „Jak user za długie hasła wpisuje, to system często się psuje”? ;D

Każdy mający zielone pojęcie programista stosuje „zasolone” hashe, które są odporne na ataki listą wcześniej wygenerowanych par hasłohash.

Z resztą nikt z zewnątrz nie ma dostępu nawet do hasha.

Ograniczenie długości czy złożoności hasła jest oczywiście bezsensowne i chyba wymyślone tylko przez manadżera projektu, który chciał łaskawie „ułatwić” życie programistom.

Zahashować można dowolnie długi i skomplikowany ciąg, a w rezultacie i tak zawsze otrzyma się stałej dłguości ciąg idealny do składowania w bazie.

Długość to i tak niewielki problem haseł. Gorzej jest jak ktoś używa oczywistych haseł – takich samych jak nazwa użytkownika, imie ulubionego zwierzaka, itp. W takich przypadkach czyjeś hasło nawet da się wygooglać :D

Otóż, jak wiadomo, algorytm MD5 został złamany – tzn. możliwe jest wygenerowanie w sensownie krótkim czasie wiadomości o zakładanym skrócie (algorytm nie został ujawniony). Im większą dajemy swobodę użytkownikowi w ustaleniu hasła, tym większy jest zbiór możliwych wiadomości (inaczej: tym więcej unikalnych haseł można wygenerować). A co za tym idzie, zwiększa się szansa, na wystąpienie dwóch (lub więcej) wiadomości posiadających ten sam skrót. Tym samym zwiększa się szansa na wygenerowanie wiadomości nie będącej hasłem, posiadającej taki sam skrót jak hasło.
Teraz wystarczy więc zdobyć listę skrótów MD5 i algorytm ;)

Oczywiście, nie sądzę, aby ktokolwiek brał pod uwagę to, co napisałem.
Bardziej prawdopodobne jest to, że podczas projektowania struktury bazy danych trzeba podjąć decyzję o maksymalnym rozmiarze pola. I każdy wybiera taką długość, jaka wydaje się mu stosowna.