Wpis z mikrobloga

@kindred: dlaczego? technicznie nie ma żadnych przeciwskazań, jedynym ograniczeniem może byc długość hasła (ale mówimy tu raczej o baaaaaardzo długich hasłach - funkcje haszujacą można karmić strumieniowo, kawalek po kawałku, więc jedyny problem to w samym przepchnięciu żądania po HTTP i obsłużeniu go przez daemon HTTP).

to, że niektórzy narzucają jakieś durne wymogi / ograniczenia, to tylko ich fantazja, nic więcej.
@frode no tylko weź potem obsłuż jakieś legacy przeglądarki albo różne charsety, to nie jest sztuczne ograniczenie. Ale znam firmy, które wymagają od programistów/vendorow żeby hasło mogło zawierać znaki specjalne, tymi Emoji i japońskie znaki xD
@R4vPL: co ma przeglądarka i charset do tego? po stronie serwera traktujesz to jako dane binarne i tyle, karmisz tym hash context i bajo, dostajesz na wylocie skrót o stałej długości którego używasz dalej. im krócej przetwarzasz surowe hasło, tym lepiej.
@frode no to że inaczej może to zaencodowac, jak masz systemy które przekazują potem to hasło do AD już tak kolorowo nie jest. Jak to #!$%@? sha256 albo bcryptem i wrzucasz do bazy to luz, ale systemy w dużych firmach tak nie działają. Bo on musi tym hasłem się uwierzytelnić dalej do AD.
@R4vPL: ok, masz tutaj rację że niektóre starożytne usługi typu AD narzucają takie ograniczenia, nie pomyślałem o tym zupełnie. problemy z kodowaniem rówież mogą się zdarzyć, ale tyczy się to równie starożytnych klientów (wszystko z czym mam styczność nowsze niż 10 lat obsługuje pełne Unicode).