Użytkownik "nightwatch77" napisał w wiadomości grup
dyskusyjnych:f61a4934-81bc-4ac8-b362-d6437842572a@p1
0g2000yqi.googlegroups.com...

>Dzizas, chłopaki, ale kombinujecie. Czy w ogole jest wymagany podpis
>kryptograficzny? Nie widzialem tu takiego wymagania i nie sądzę że

A tak z ciekawości - ile kosztuje certyfikowany zgodny z PN e-podpis? Czy
naprawdę firmy nie stać na taki podpis dla Pana Kierownika - zwłaszcza, że
przydałby się pewnie i do innych rzeczy niż podpisywanie Bardzo Ważnych
Wewnętrznych Papierków?

>historii - pokazać kierownikowi okienko decyzji i niech wybierze
>odpowiednią opcję. Uwierzytelnieniem tego jest sama aplikacja ktora

Bardzo szybko okaże się, że:

1. Zamiast kierownika klika jego sekretarka (za wiedzą lub bez).
2. Zamiast kierownika klika jego nad-kierownik (bo skoro jest szefem szefa
to czemu nie?)
3. Administrator systemu może wszystkich wyręczyć w dowolnym czasie i nawet
z antydatowaniem.

>autentykacji, czy to domena czy cokolwiek innego. Zakładamy że tylko
>kierownik zna swoje hasło do aplikacji i że każdy pracuje na swoim
>koncie - ale to chyba normalne?

Zapominasz o administratorze/informatyku.



Po podjęciu decyzji można kierownikowi wysłać potwierdzenie mailem
albo smsem, żeby mógł zweryfikować czy się nie pomylił albo czy ktoś
się pod niego podszył - no i będzie miał ślad gdyby np ktoś zmienił
jego decyzję grzebiąc bezpośrednio w bazie.
Co do dodatkowych zabezpieczeń przed grzebaniem w bazach aplikacji -
pomysł z md5 jest chyba wystarczający, ale wg mnie to i tak za daleko
idące zabezpieczenie. Jeśli ktoś może grzebać w bazie to pwnie może
też np zmienić hasło domenowe i podszyć się pod innego użytkownika tak
że nikt tego nie wykryje. No ale jeśli firma nie ufa swoim adminom to
ma problem kadrowy a nie kryptograficzny.
R

do góry

On 2011-08-29 12:14, slawek wrote:
> Użytkownik "nightwatch77" napisał w wiadomości grup
> dyskusyjnych:f61a4934-81bc-4ac8-b362-d6437842572a@p1
0g2000yqi.googlegroups.com...
>
>
>> Dzizas, chłopaki, ale kombinujecie. Czy w ogole jest wymagany podpis
>> kryptograficzny? Nie widzialem tu takiego wymagania i nie sądzę że
>
> A tak z ciekawości - ile kosztuje certyfikowany zgodny z PN e-podpis?
> Czy naprawdę firmy nie stać na taki podpis dla Pana Kierownika -
> zwłaszcza, że przydałby się pewnie i do innych rzeczy niż podpisywanie
> Bardzo Ważnych Wewnętrznych Papierków?
>

Z czytnikiem i karta ok 2-3 stowek PLN :)
Ale trzeba by zatrudnic b. drogiego konsultanta, zeby podpowiedzial, ze
to taniej niz programista dlulbiacy 2miesiace (psujesz rynek tak swoja
droga).

A po drugie - NIH syndrome.

--
Michal

do góry

On 29 Sie, 12:54, Michal Kleczek <k...@p...onet.pl> wrote:
> On 2011-08-29 12:14, slawek wrote:
>
> > Użytkownik "nightwatch77" napisał w wiadomości grup
> > dyskusyjnych:f61a4934-81bc-4ac8-b362-d64378425...@p1
0g2000yqi.googlegroups.com...
>
> >> Dzizas, chłopaki, ale kombinujecie. Czy w ogole jest wymagany podpis
> >> kryptograficzny? Nie widzialem tu takiego wymagania i nie sądzę że
>
> > A tak z ciekawości - ile kosztuje certyfikowany zgodny z PN e-podpis?
> > Czy naprawdę firmy nie stać na taki podpis dla Pana Kierownika -
> > zwłaszcza, że przydałby się pewnie i do innych rzeczy niż podpisywanie
> > Bardzo Ważnych Wewnętrznych Papierków?
>
> Z czytnikiem i karta ok 2-3 stowek PLN :)
> Ale trzeba by zatrudnic b. drogiego konsultanta, zeby podpowiedzial, ze
> to taniej niz programista dlulbiacy 2miesiace (psujesz rynek tak swoja
> droga).
>
> A po drugie - NIH syndrome.
>
> --
> Michal

No i co, myślisz że jak kupisz ten podpis czy kartę to koniec
problemu? Raczej jego początek... Programistę będziesz musiał wziąć
tak czy siak a na końcu się okaże że i tak wszystko jest dziurawe albo
skrajnie niepraktyczne i zwykła domena windows była by
najsensowniejsza (no ale wtedy to już nikt nie przyzna się do błędu
tylko wszyscy będą kombinować jak ten wspaniały system obejść).

do góry

"Stachu 'Dozzie' K." napisał:

> On 2011-08-27, Edek <e...@g...com> wrote:
[...]
> To odpieprz się od próby implementowania podpisu cyfrowego, jeśli nie
> czujesz się ekspertem od kryptografii. To nie jest coś co "się zrobi
> i będzie dobrze", jak, nie przymierzając, system katalogowania książek
> w bibliotece.

Ok. Odpieprzam się i zaraz się pokajam, a teraz jeszcze sobie poględzę.

>>>>>> Utrata klucza prywatnego powoduje, że trzeba zmienić klucz
>>>>>> publiczny też.
>
>>>>> Kazdy system ma revoke.
>
>>>> Utrata != poznanie przez osobę niepowołaną. Poza tym, stare dokumenty
>>>> przy revoke trzeba by podpisać jeszcze raz, chyba że mają stempel
>>>> czasu i ktoś magicznie wie, że klucz prywatny nie upublicznił się
>>>> przed tą datą, wtedy można zrobić revoke od jakiejś daty. Można
>>>> też mieć inny mechanizm, ale sam podpis PGP nie wystarczy.
>
>>>> Czasami myli się revoke kluczy SSL z revoke kluczy podpisu. To
>>>> drugie wpada w tą samą kategorię, co perfect forward secrecy.
>
>>> Jsli utraciles kontrole nad kluczem to znaczy ze jest publicznie znany.
>
>> Nie jestem ekspertem, ale chyba jednak nie.
>
> Ale chyba jednak tak. Zawsze przy projektowaniu kryptosystemów zakłada
> się najgorszy przypadek pasujący do modelu ataku.

No nie. Sam fakt, że istnieją systemy używające wymiany po łączach
niezabezpieczonych temu przeczy. A jak ktoś podsłucha łącze, to
zakłada się, że wszystko już jest znane?

Nie wiem, jakie są skuteczne modele ataku na ten mój genialny 10minutowy
pomysł i nie o to chodzi.

>
>> Ok: na USB (typu pendrive z plikami) jest klucz owinięty
>> hasłem usera owinięty jednorazowym kluczem serwera podpisującego
>> (wszystko symetrycznym).
>
>> Samo zgubienie USB nie powoduje poznania klucza: bez hasła
>> jest totalnie bezużyteczny. Natomiast powoduje jego utratę.
>> Nie da się też łamać hasła bez znajomości klucza serwera.
>
>> Czyli: można czytając A podpisać B, albo zamiast NIE AKCEPTUJE
>> podpisać AKCEPTUJE.
>
> Właściwie nie widzę jak można podpisać *cokolwiek* przy takim opisie
> systemu.

Bardziej formalnie:
K - prywatny klucz asymetryczny użytkownika
Sn - klucz serwera (symetryczny)
C - klucz klienta = hash(hasło) (symetryczny)
D - dokument
username - username

Na USB jest
Sn { C { K } } (czyli ciasteczko), gdzie X{y} oznacza y zaszyfrowany
symetrycznie kluczem X

Wymiana zachodzi tak, że klient łączy się po SSL z serwerem
podpisującym:
Client <--> Serwer

1. --> C
--> ciasteczko z USB
--> D
--> username
2. Serwer wyciąga ze swojej bazy Sn(username)
Ponieważ ma Sn i C, z ciasteczka bierze K
Podpisuje dokument D używając K
Generuje Sm, m = n+1 (losowy klucz Sm)
generuje nowe ciasteczko Sm { C { K } }
3. <-- Ok,
<-- (podpisany dokument, albo podpis, i takie tam)
<-- nowe ciasteczko
4. Klient zapisuje ciasteczko i potwierdza
--> OK
5. Serwer zapisuje w bazie Sm (jako nowy Sn) pod username

Cechy:
- klucz w postaci jawnej jest tylko na serwerze w czasie
podpisywania; nie jest tam przechowywany. No, kiedyś
gdzieś go trzeba stworzyć...
- na usb klucz również nie jest w postaci jawnej - do jego
poznania wymagane jest hasło i klucz serwera. Banalnie można
zmodyfikować system, żeby hasło i klucz serwera nie
wystarczały, ale nie wiem po co
- hasło nigdzie nie jest zapamiętywane jawnie (ani generowany
z niego klucz)
- klucz jednorazowy serwera jest przechowywany na serwerze
- ciasteczko działa raz
- sam podpis jest dokładnie typu PGP, czyli zwykły asymetryczny,
weryfikuje się publicznym kluczem "do pary"

>
>> Jedyne, co widzę, to to, że nawet czytający podpisany dokument
>> może czytać coś innego niż było podpisane. Pytanie jest o
>> niezbędny poziom paranoi. Trzymam się wersji "dla ubogich".
>
> Weź ty się lepiej zgłoś do jakiejś uczelni, która ma pracujący zespół
> kryptologów i niech oni ci zaprojektują kryptosystem, a nie będziesz
> paprał samodzielnie.

To miało tylko pokazać, że twierdzenie "zgubienie nośnika oznacza
upublicznienie klucza" jest baardzo definitywnym stwierdzeniem. Ten
"system" powstał tylko jako ilustracja, i nie polegałbym na mojej
kilkuminutowej tfurczości na tyle, żeby to implementować.

Na swoją obronę mam tylko tyle, że to co zaproponowałem działa,
w przeciwieństwie do "pomysłu z md5". Jakiś błąd w logice?
Nie pytam, na ile jest bezpieczny, szkoda czasu...
Przypuszczam, że lepsze rzeczy można wygooglać. I nie jest to
podpis, tylko zarządzanie kluczem.

Co do kryptologów, to rozdzieliłbym znajomość matematycznych podstaw
działania algorytmów kryptograficznych od znajomości ich właściwości.
Założę się, że więcej ludzi rozumie różnicę pomiędzy szyfrowaniem
asymetrycznym a symetrycznym niż matematyczne podstawy któregokolwiek
z możliwych algorytmów.

Edek

PS. Ozszzo chodzi z tymi serwerami, na jednym widać jedne posty, na
innych inne?

do góry

slawek wrote:

> Użytkownik "A.L." napisał w wiadomości grup
> dyskusyjnych:i5if57d47lnl8cfhce680edf4hju468aso@4ax.
com...
>
>>DOWOLNA rzecz ma skutki prawne, nawet uzywana wewnatrz firmy, jezeli
>>nastapi jakis wypadek, utrata mienia, itede, i pojawi sie sprawa
>
> 100% zgody.
>
> Myślę, że problem redukuje się do: "jak zrobić podpis elektroniczny ale
> tak aby to nie był podpis elektroniczny".

Generalnie tak. Dlatego pomysly były takie by podpis sluzyl tylko dla
wewnetrznego obiegu w serwerach czy sieci a wszystko i tak opieralo sie na
logowaniu.
Dlatego tez proponowalem te logowanie nieco usprawnic.
Bardzo podobalo mi sie stwierdzenie zapytaj prawnika ;)

do góry

Edek wrote:

> [nie po kolei...]
> > Ty wez przeczytaj o czym inni pisza dobrze?
> >
>
> Point. Nie próbuję być ekspertem, którym nie jestem, może być, że
> nie wszystko od razu rozumiem.
>
> Przy czym, staram się trzymać tematu "dla ubogich", co może naiwnie
> rozumiem jako "bez sprzętowego sekretu" i bez jednorazowych haseł
> na zdrapce czy czymś podobnym.
> Sprzętowy sekret psuje zabawę o tyle, że z nim jest o niebo łatwiej.
> Zdrapka czy inne jednorazowe hasła też.

A teraz ja nie rozumiem. Dlaczego kartka papieru miala by byc jakims
strasznie trudnym, drogim (niepotrzebne skreslic) rozwiazaniem?
Teraz ja napisze co rozumiem pod tym co okresliles podpis dla ubogich.
Prosto by szef byl zadowolony, ale by poziom zaszyfrowania i integralnosci
danych (np. archiwizacji, przesyłu, dostepu dla roznych osob nie majacych
prawa wiedziec co ktos decyduje wie) był lepszy niz serwer + php
Tak tez napisalem ze swojej strony.

>>>>> Utrata klucza prywatnego powoduje, że trzeba zmienić klucz
>>>>> publiczny też.
>>>>
>>>> Kazdy system ma revoke.
>>>
>>> Utrata != poznanie przez osobę niepowołaną. [...]
>>> Czasami myli się revoke kluczy SSL z revoke kluczy podpisu. To
>>> drugie wpada w tą samą kategorię, co perfect forward secrecy.
>>
>> Jsli utraciles kontrole nad kluczem to znaczy ze jest publicznie znany.
>>
>
> Nie jestem ekspertem, ale chyba jednak nie.
>
> Ok: na USB (typu pendrive z plikami) jest klucz owinięty
> hasłem usera owinięty jednorazowym kluczem serwera podpisującego
> (wszystko symetrycznym).

ja proponowalem yubico ew. samorobke. troszke cos innego.

> Samo zgubienie USB nie powoduje poznania klucza: bez hasła
> jest totalnie bezużyteczny. Natomiast powoduje jego utratę.
> Nie da się też łamać hasła bez znajomości klucza serwera.

No przyznam ze niestety nie. Moje rozwiazanie zazwyczaj uzywa prostego
hasla+ klucz wiec niestety kradziez klucza oznacza 90% szans na złamanie
systemu. W koncu jak ktos ma klucz to haslo ma pewnie 8 znakowe.

> Czyli: można czytając A podpisać B, albo zamiast NIE AKCEPTUJE
> podpisać AKCEPTUJE.
>
> Ale też:
> jak ktoś skopiuje USB i ma hasło i podpisze C, to serwer nie podpisze
> kolejnego dokumentu D przy użyciu USB. Ktoś musiałby podmienić na
> oryginalnym USB ciasteczko na to "po podpisaniu C". Przy kontroli
> nad jednym komputerem (czytaj: OS) jest to banalne, przy kilku OS,
> np jednym Thin Client, sprawa szybko się rypnie.
> Serwer może od usera wymagać, żeby raz na kiedyś z czystego systemu
> przejrzał listę dokumentów. Wymaga chwili, żeby przejrzeć możliwości
> "podrzucenia" podpisanego dokumentu.

yubico da sie przeprogramowac, samorobka oczywiscie tez.

> Czego nie zauważyłem?
>
> Jedyne, co widzę, to to, że nawet czytający podpisany dokument
> może czytać coś innego niż było podpisane. Pytanie jest o
> niezbędny poziom paranoi. Trzymam się wersji "dla ubogich".

no jak widac poziom paranoi i ubogosci rozwiazania nie sa terminami jasnymi
dla obu stron, a pewnie co dopiero dla pytajacego.

> [1] A tak naprawdę nie klucza, tylko ciasteczka. Klucz jest bezpieczny
> w środku.

Ale klucz mozna wyjac, chyba ze masz dostep do szyfrowanych prockow.
Po za tym sa systemy troszke bardziej skomplikowane niz zwykle PPP. Masz tam
np. poprzedni wynik albo stan maszyny i lecisz strumieniowo. Do logowania
akurat wazne. Bo nie da sie zalogowac jesli zgubisz i wygenerujesz sobie
drugi klucz. Albo jesli zalogujesz sie z lokalizacji niemozliwej do
wykonania.

do góry

Edek wrote:

>> Samo zgubienie USB nie powoduje poznania klucza: bez hasła
>> jest totalnie bezużyteczny. Natomiast powoduje jego utratę.
>> Nie da się też łamać hasła bez znajomości klucza serwera.
>
> ... i nie da się poznać klucza znając hasło, ale nie znając klucza
> serwera...
>
> Zapomniałem dodać oczywistego.

zgoda

do góry

Edek wrote:

> "Stachu 'Dozzie' K." napisał:
>
>> On 2011-08-27, Edek <e...@g...com> wrote:
> [...]
>> To odpieprz się od próby implementowania podpisu cyfrowego, jeśli nie
>> czujesz się ekspertem od kryptografii. To nie jest coś co "się zrobi
>> i będzie dobrze", jak, nie przymierzając, system katalogowania książek
>> w bibliotece.
>
> Ok. Odpieprzam się i zaraz się pokajam, a teraz jeszcze sobie poględzę.

Stachu doze to znany troll daj se luz i wrzuc do killfile.

do góry

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.

do góry

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.

do góry