Wnioski słuszne - zamiast od razu rzucać na stół podręcznik do
kryptografii lepiej się zastanowić nad używalnością rozwiązania.
Ktoś tu stwierdził że nie można polegać na loginie i haśle bo ten
kierownik na pewno rozda swoje hasło zastępcy, sekretarce i szefowi.
A ja bym się zastanowił dlaczego ów kierownik ma komuś dawać swoje
hasło - otóż dlatego że chce on zlecić zastępcy wykonanie jakiejś
czynności w swoim imieniu albo delegować częśc swojej
odpowiedzialności na kogoś innego a aplikacja po prostu nie ma takiej
funkcji. Często aplikacje biurowe nie obsługują nawet zastępstw a
wiadomo że ludzie nagminnie przekazują obowiązki zastępcom (urlopy,
choroby). Ta wada i inne podobne braki w logice aplikacji zmuszają
ludzi do obchodzenia zabezpieczeń systemu i nawet gdyby
zabezpieczeniem był klucz kryptograficzny to nikogo on nie powstrzyma
- po prostu kierownik idąc na urlop da swój klucz sekretarce a ta
będzie go wręczać wszystkim którzy przejęli obowiązki kierownika.
Wymyślony system zabezpieczeń musi być praktyczny i łatwy w obsłudze
tak żeby ludzie nie musieli go oszukiwać i żeby nie wstrzymywał pracy
w firmie tylko dlatego że projektant czegoś nie przewidział. To jest
największa 'dziura' w bezpieczeństwie gdy użytkownicy są zmuszeni do
ignorowania procedur. Uważam że aplikacja biurowa powinna minimalnie
ograniczać użytkownika (nie narzucać sztywnych reguł) ale za to
powinna wszystkie działania tego użytkownika rejestrować i pokazywać w
historii dokumentu. Podstawą tego jest wiarygodny i nieuciążliwy
mechanizm uwierzytelniania, najlepiej taki którego w ogóle nie widać.

R

On 30 Sie, 10:38, Jacek Czerwinski <x...@...z.pl> wrote:
> W dniu 2011-08-29 20:33, Grzegorz Wądzik. pisze:
>
> > Edek wrote:
>
> >> [nie po kolei...]
> > no jak widac poziom paranoi i ubogosci rozwiazania nie sa terminami jasnymi
> > dla obu stron, a pewnie co dopiero dla pytajacego.
>
> Dokładnie.
> Pytający rzucił pewnego rodzaju sondę i dziękuje za wypowiedzi.
> Pozwolę sobie podsumować:
> a) jest u niektórych sprzeciw, ale jest warunkowe przyzwolenie na
> lokalne, niezupełnie profesjonalne wdrożenie 'oparte o login'.
> b) rozwiązań idących "w górę" jest pełna skala.
>
> Subiektywnie wychwyciłem mocniej słowa 'niezaprzeczalność' oraz coś co
> nazwę 'zaufanie' (do algorytmu, admina, programisty integrującego to
> wszystko, itd) Zrozumiałem, że "pełnego" podpisu tu nigdy nie będzie
> choćby przez to, że jeszcze jeden podsystem i jeszcze jedno 'hasło'
> (pewien popularny obraz, jaki uzytkownik by doświadczał) to zbyt duży
> szok. A skoro szok, to trzeba zmniejszyć, więc nawet dobre biblioteki
> trzeba by zintegrowac z GUI itd, znacznie osłabia się projekt, od razu
> pytanie, co programista zrobi z hasłem itd. Tip-Top i matematycznie
> doskonale to na pewno nie będzie.
>
> Zdecydowanie z tego wątku wyniosłem myśl, że kontekst prawno-kadrowy
> rozwiązania trzeba dobrze sprawdzić i opisać (również streszczenie dla
> end-usera by stało się częścią jakiegoś regulaminu).
>
> PS. "ubogość" nawet niekoniecznie w wymiarze finansowym (choć budżet
> ogromny nie może być), ale organizacyjnym, edukacyjnym itd. Dostatecznie
> dużym problemem jest jedno DOBRE hasło, takie realia.