Paweł Goleń, blog

To co przedstawię poniżej jest moim luźnym pomysłem, który na razie nie doczekał się nigdzie realizacji. Na chwilę obecną zastanawiam się, czy ma on sens...

Czy hasło powinno być losowe? Pierwsza odpowiedź nasuwa się sama - oczywiście, że tak! Tylko jak to zrobić? W chwili, gdy zatrudniana osoba pojawia się w systemie kadrowym (lub jest wprowadzana do firmy w inny sposób, nie wszyscy pracownicy przechodzą przez kadry), system IdM wychwytuje ten fakt i tworzy dla tej osoby "obiekt person", który jest później wykorzystywany do logowania do systemu zarządzania hasłami. Ten obiekt będzie jakoś nazwany, może to być na przykład numer ewidencyjny pracownika przydzielony przez system kadrowy. Czyli umówmy się, że identyfikatorem takiego obiektu jest ciąg 001765. System IdM w chwili tworzenia obiektu dla nowej osoby ustawia hasło, które trzeba przekazać w jakiś sposób szczęśliwemu posiadaczowi wymienionego wyżej numeru identyfikacyjnego. W świecie idealnym system IdM wyplułby na drukarkę igłową losowo wygenerowane hasło, które wydrukowane zostałoby wewnątrz zamkniętej koperty, tak jak ma to miejsce na przykład w przypadku kodów PIN do kart płatniczych. Koperta taka zostałaby następnie przekazana pracownikowi, który rozrywając ją i odczytując informację o swoim numerze identyfikacyjnym oraz haśle mógłby zalogować się do modułu zarządzania hasłami. Niestety, w przypadku firmy pewnej wielkości, która dodatkowo jest rozprzestrzeniona geograficznie i w której nie w każdej lokalizacji jest stosowny dział HR taki pomysł powoduje kilka problemów logistycznych, które koncepcję tą uśmiercają w zarodku. Koncepcją alternatywną jest przechowywanie w jakiejś bazie par numer ewidencyjny i hasło oraz przygotowanie aplikacji, która po wpisaniu numeru ewidencyjnego stosowne hasło wyświetli. Problem - w jaki sposób zapewnić, że dana osoba będzie oglądała tylko hasło startowe inicjalne tylko dla swojego numeru identyfikacyjnego? Mój pomysł jest nieco inny - zamiast hasła losowego tworzę funkcję, która w prosty i jednoznaczny sposób przekształca numer ewidencyjny na hasło startowe. Kroki tej funkcji mogą być następujące: function InitialPassword(PersonID,Key) { s = HMAC(PersonID,Key); s = base64(s) return s.substring(10) }

Funkcja ta przyjmuje dwa parametry, powszechnie znany numer ewidencyjny pracownika, oraz tajny klucz. Na tych dwóch argumentach wykonywana jest funkcja HMAC, której wynikiem jest jakiś ciąg danych nie koniecznie unikalnych. Ponieważ ten ciąg danych jest średnio czytelny, proponuję zakodować go przy pomocy base64 i wykorzystać pierwsze 10 znaków z wyniku. Przykładowe hasła (PersonID, hasło startowe) wygenerowane w ten sposób przedstawiam poniżej:

ff000000 YjNlOGQzNm ff000001 ZjZkOTkwMm ff000002 ZDAxYjk1Zj ff000003 N2UwYWIxMm ff000004 YmQ2Zjg5ZD ff000005 Mzk4MDRmMj ff000006 YTlhM2Q0YW ff000007 MDg2NzcwN2 ff000008 NDI5MzkwNG ff000009 NDViNGM1OD

Hasła może nie są szczytem złożoności, nie mają znaków specjalnych, ale przy okazji są tak niepodobne do niczego, że chyba się do wykorzystania tylko jeden raz nadają.

Tak wygenerowane hasło może zostać ustawione dla obiektu nowo stworzonej osoby. Jak teraz przekazać hasło nowemu pracownikowi? Jest to kwestia specyfiki firmy, ale zdarza się tak, nawet dość często, że nowa osoba ma swojego przełożonego. Informacja o zatrudnieniu tej osoby wraz z pewnymi innymi danymi, jest do przełożonego tej nowej osoby przesyłana z działu HR. W takim razie można stworzyć drobną aplikację internetową, która będzie przyjmowała dwa parametry, wspomniany już wcześniej numer ewidencyjny PersonID oraz pewien klucz. Do przełożonego osoby wraz z danymi o zatrudnionej osobie przesyłany byłby link do tej strony. W tym celu po stronie HR należałoby stworzyć prostą aplikację (być może webową), która na wejściu przyjmowałaby numer ewidencyjny zatrudnianej osoby, a na wyjściu podawałaby adres postaci http://serwer/aplikacja?PersonID=PersonID&Ticket=ticket. Dla pewności dostęp do tej aplikacji należałoby ograniczyć do kilku osób z działu HR, którzy zajmują się zatrudnianiem nowych pracowników. Link taki byłby przesyłany do przełożonego nowej osoby, przełożony ten wchodziłby na podany adres i drukował wyświetlaną stronę. Cóż, zobaczyłby owe tajne hasło, ale komuś w końcu trzeba ufać... Dla pewności dostęp do tej aplikacji należałoby zawęzić dla grupy osób będącej przełożonymi (kierowników, dyrektorów). Wydrukowana kartka byłaby przekazywana nowej osobie, która w spokoju zmieniałaby hasło startowe na nowe przy okazji ustawiając sobie hasła w pozostałych systemach. Po co ten dodatkowy ticket. Cóż, tak na wszelki wypadek, by przełożony nie bawił się aplikacją wpisując do niej kolejne numery ewidencyjne. Ticket jest w moim zamierzeniu niczym innym niż wynikiem funkcji HMAC(PersonID,InnyTajnyKlucz). Aplikacja przeznaczona dla przełożonych weryfikowałaby, czy podany numer identyfikacyjny zgadza się z drugim parametrem swojego wywołania i tylko w takim przypadku wykonywała swoje zadanie.

W tym scenariuszu mamy następujące kroki:

• Automatyczne wygenerowanie hasła dla nowego obiektu na podstawie numeru identyfikacyjnego i tajnego klucza, K1,
• Ręczne (niestety) wygenerowanie informacji dla przełożonego o adresie, pod którym może uzyskać hasło startowe dla swojego nowego pracownika przy użyciu klucza K2,
• Ręczne (no na coś się w końcu człowiek musi przydać!) uruchomienie aplikacji, która na podstawie otrzymanego adresu, oraz kluczy K1 oraz K2 przygotuje stronę z informacjami dla nowego pracownika,
• Wydrukowanie i przekazanie tej strony nowemu pracownikowi,
• Zmiana hasła startowego przez nowego pracownika,

W schemacie tym boli mnie kilka rzeczy. Po pierwsze wykorzystanie kluczy K1 oraz K2. Po drugie to, że klucze te muszą być co najmniej w dwóch miejscach... I pewnie jeszcze coś wymyślę, jak się nad tym zastanowię...

Jeśli bardziej zastanowić się, to analogiczny schemat można zastosować w przypadku haseł generowanych losowo. Zmiany byłyby takie, że po pierwsze system IdM musiałby jednak odnotować w bazie losowo wygenerowane hasło, a po drugie aplikacja przeznaczona dla przełożonego musiałaby do tej bazy sięgać. Problem patrzenia na "nie swoje" numery ewidencyjne można rozwiązać za pomocą wprowadzonego już przeze mnie parametru ticket dokładnie w sposób opisany powyżej. Hasła startowe mogłyby być wówczas "lepsze" (choćby generowane za pomocą programu apg). Dalej to nie byłaby wspominana przeze mnie "zamknięta koperta", ale...

...ale o czym my rozmawiamy, skoro często hasło startowe ma postać 123456, jest jednakowe dla wszystkich i podawane przez telefon?