W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:
> On 30 Sty, 16:19, Rafał Maszkowski<r...@i...edu.pl> wrote:
>> In pl.hum.polszczyzna xbartx<b...@h...net> wrote:
>
>>> No i też urządzeniem jeżeli mamy na myśli token sprzętowy np RSA. Lista
>>> haseł to taki substytut sprzętowego tokena, żeby nie powiedzieć jego
>>> biedniejszy krewny ;)
>>
>> Tak naprawdę to jest to token generator, który wytwarza tokeny/hasła.
>> Wydrukowana lista haseł to produkt takiego generatora, który jest za
>> duży żeby go trzymać w kieszeni.
>
> Nie ma żadnego powodu, aby hasła na liście pochodziły z jakiegokolwiek
> generatora. Lepiej, aby były losowane.

Ech, humaniści.
Losowane oczywiście za pomocą sierotki? Bo te wylosowane z komputera, są
losowane za pomocą _generatora_ liczb pseudolosowych.

A wracając do meritum - jak w takim razie (losowe kody) druga strona
miałaby zweryfikować poprawność takiego kodu?

--
Pete

do góry

On 2010-01-11 03:18, Marcin Gryszkalis wrote:
> z...@o...pl wrote:
>> czy token lub lista haseł jednorazowych jest instrumentem?
>> urządzeniem? narzędziem?
>
> Istotne w procesie autoryzacji jest samo hasło (jednorazowe), lista haseł
> jest po prostu nośnikiem takich haseł a token jest ich generatorem.
>
> Sama karta nie jest żadnym szczególnym bytem, bo hasła można przepisać na
> kartkę w zeszycie albo zrobić karcie zdjęcie.
>
> Hasło natomiast nie jest instrumentem ani narzędziem tylko parametrem
> autoryzacji (która z kolei jest funkcją).

Gwoli ścisłości:

http://pl.wikipedia.org/wiki/Uwierzytelnianie
http://pl.wikipedia.org/wiki/Autoryzacja_%28informat
yka%29

Więc w procesie autoryzacji hasło nie ma żadnego znaczenia :) Wcześniej
powinno mieć miejsce uwierzytelnienie (zwane też, niepoprawnie jak
twierdzi Wikipedia, autentykacją) i tyle :)

G.

do góry

On 30 Sty, 20:41, Pete <n...@n...com> wrote:
> W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:
>
> > On 30 Sty, 16:19, Rafał Maszkowski<r...@i...edu.pl>  wrote:
> >> In pl.hum.polszczyzna xbartx<b...@h...net>  wrote:
>
> >>> No i też urządzeniem jeżeli mamy na myśli token sprzętowy np RSA. Lista
> >>> haseł to taki substytut sprzętowego tokena, żeby nie powiedzieć jego
> >>> biedniejszy krewny ;)
>
> >> Tak naprawdę to jest to token generator, który wytwarza tokeny/hasła.
> >> Wydrukowana lista haseł to produkt takiego generatora, który jest za
> >> duży żeby go trzymać w kieszeni.
>
> > Nie ma żadnego powodu, aby hasła na liście pochodziły z jakiegokolwiek
> > generatora. Lepiej, aby były losowane.
>
> Ech, humaniści.

taaa, spec się odezwał :-)

> Losowane oczywiście za pomocą sierotki? Bo te wylosowane z komputera, są
> losowane za pomocą _generatora_ liczb pseudolosowych.

http://en.wikipedia.org/wiki/Hardware_random_number_
generator

>
> A wracając do meritum - jak w takim razie (losowe kody) druga strona
> miałaby zweryfikować poprawność takiego kodu?

Porównać z listą przechowywaną w bazie, Watsonie :-)

--
pozdrawiam,
Jarek Andrzejewski

do góry

W dniu 01.02.10 11:16, Jarek Andrzejewski pisze:
> On 30 Sty, 20:41, Pete<n...@n...com> wrote:
>> W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:
>>
>>> On 30 Sty, 16:19, Rafał Maszkowski<r...@i...edu.pl> wrote:
>>>> In pl.hum.polszczyzna xbartx<b...@h...net> wrote:
>>
>>>>> No i też urządzeniem jeżeli mamy na myśli token sprzętowy np RSA. Lista
>>>>> haseł to taki substytut sprzętowego tokena, żeby nie powiedzieć jego
>>>>> biedniejszy krewny ;)
>>
>>>> Tak naprawdę to jest to token generator, który wytwarza tokeny/hasła.
>>>> Wydrukowana lista haseł to produkt takiego generatora, który jest za
>>>> duży żeby go trzymać w kieszeni.
>>
>>> Nie ma żadnego powodu, aby hasła na liście pochodziły z jakiegokolwiek
>>> generatora. Lepiej, aby były losowane.
>>
>> Ech, humaniści.
>
> taaa, spec się odezwał :-)

ech, humaniści...

>
>> Losowane oczywiście za pomocą sierotki? Bo te wylosowane z komputera, są
>> losowane za pomocą _generatora_ liczb pseudolosowych.
>
> http://en.wikipedia.org/wiki/Hardware_random_number_
generator
^^^^^^^^^
>
>>
>> A wracając do meritum - jak w takim razie (losowe kody) druga strona
>> miałaby zweryfikować poprawność takiego kodu?
>
> Porównać z listą przechowywaną w bazie, Watsonie :-)

Re-we-la-cyj-ne rozwiązanie!!!
Że też jeszcze wszyscy inni nie wpadli na tak genialny pomysł :P
Nie ma to jak 100% bezpieczeństwo takiego rozwiązania


--
Pete

do góry

On 2 Lut, 07:49, Pete <n...@n...com> wrote:
> W dniu 01.02.10 11:16, Jarek Andrzejewski pisze:
>
> >> A wracając do meritum - jak w takim razie (losowe kody) druga strona
> >> miałaby zweryfikować poprawność takiego kodu?
>
> > Porównać z listą przechowywaną w bazie, Watsonie :-)
>
> Re-we-la-cyj-ne rozwiązanie!!!
> Że też jeszcze wszyscy inni nie wpadli na tak genialny pomysł :P
> Nie ma to jak 100% bezpieczeństwo takiego rozwiązania

Lepiej doucz się trochę z dziedziny kryptologii :-) Właśnie takie
rozwiązanie (losowy ciąg znany obu stronom) jest najbezpieczniejszym
rozwiązaniem.
Polecam Ci rozdział 9.4 z książki "Applied Cryptography, Second
Edition: Protocols, Algorthms, and Source Code in C" Bruce Schneiera
(jest też polskie wydanie p.t. "Kryptografia dla praktyków").

--
pozdrawiam,
Jarek Andrzejewski

do góry

Jarek Andrzejewski <p...@g...com> writes:

> Lepiej doucz się trochę z dziedziny kryptologii :-) Właśnie takie
> rozwiązanie (losowy ciąg znany obu stronom) jest najbezpieczniejszym
> rozwiązaniem.

Nic z tych rzeczy, oczywiscie ze nie jest, i nie bede sprawdzal co tam
akurat Schneier w tym miejscu napisal, ale na pewno nie pisal o tym jako
o bezwzglednie najbezpieczniejszym, czy w ogole bezpiecznym rozwiazaniu.

Generalnie wszelkie metody z "shared secret" (haslem, kodami, tokenami
itp. znanym obu stronom) sa na tyle bezpieczne, na ile obie strony maja
do siebie zaufanie. Innymi slowy - sa przypadku relacji bank-klient sa
niespecjalnie bezpieczne.

Obecnie najbezpieczne jest podpisywanie zlecen w odpowiednim formacie
przy uzyciu podpisu cyfrowego. Klucz publiczny (lub np. certyfikat)
sluzacy do weryfikacji podpisu powinien byc czescia umowy miedzy
stronami. Druga strona powinna potwierdzac otrzymanie zlecenia swoim
podpisem, a jej certyfikat (klucz publiczny) powinien takze byc czescia
umowy, i powinien byc ogolnie dostepny.
--
Krzysztof Halasa

do góry

On 2 Lut, 16:19, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Jarek Andrzejewski <p...@g...com> writes:
> > Lepiej doucz się trochę z dziedziny kryptologii :-) Właśnie takie
> > rozwiązanie (losowy ciąg znany obu stronom) jest najbezpieczniejszym
> > rozwiązaniem.
>
> Nic z tych rzeczy, oczywiscie ze nie jest, i nie bede sprawdzal co tam
> akurat Schneier w tym miejscu napisal, ale na pewno nie pisal o tym jako
> o bezwzglednie najbezpieczniejszym, czy w ogole bezpiecznym rozwiazaniu.
>
> Generalnie wszelkie metody z "shared secret" (haslem, kodami, tokenami
> itp. znanym obu stronom) sa na tyle bezpieczne, na ile obie strony maja
> do siebie zaufanie. Innymi slowy - sa przypadku relacji bank-klient sa
> niespecjalnie bezpieczne.

Bezpieczeństwo metody szyfrowania z losowym ciągiem (kluczem) polega
na tym, że kryptoanaliza przechwyconej transmisji nie jest niemożliwa.
Po prostu wynikiem jest tez losowy ciąg.
Ja miałem na myśli, że lepsze losowo generowane liczby na liście +
kopia w bazie niż generowane przy pomocy deterministycznego algorytmu,
którego złamanie jest przecież możliwe.

> Obecnie najbezpieczne jest podpisywanie zlecen w odpowiednim formacie
> przy uzyciu podpisu cyfrowego. Klucz publiczny (lub np. certyfikat)
> sluzacy do weryfikacji podpisu powinien byc czescia umowy miedzy
> stronami. Druga strona powinna potwierdzac otrzymanie zlecenia swoim
> podpisem, a jej certyfikat (klucz publiczny) powinien takze byc czescia
> umowy, i powinien byc ogolnie dostepny.

słuszna uwaga.

--
pozdrawiam,
Jarek Andrzejewski

do góry

Jarek Andrzejewski <p...@g...com> writes:

> Bezpieczeństwo metody szyfrowania z losowym ciągiem (kluczem) polega
> na tym, że kryptoanaliza przechwyconej transmisji nie jest niemożliwa.

No, tak :-)
Ale token i haslo jednorazowe nie sluzy do szyfrowania, a tylko do
potwierdzenia, ze druga strona jest ta, za ktora sie podaje.

To zreszta bardzo stary wynalazek, i znane skuteczne ataki na niego
takze sa bardzo stare.

> Ja miałem na myśli, że lepsze losowo generowane liczby na liście +
> kopia w bazie niż generowane przy pomocy deterministycznego algorytmu,
> którego złamanie jest przecież możliwe.

Nikt w praktyce nie generuje takich rzeczy deterministycznym algorytmem,
to bylaby przesada. Tzn. oczywiscie sa rozne OTP, ktore moga miec taka
wlasciwosc, ze z nastepnego hasla mozna wyprowadzic poprzednie. Ale
w druga strone to nie dziala.

Wlasciwie teraz chyba nawet najslabsze algorytmy pseudolosowe sa
w praktyce nie do zlamania, pomijajac specjalnie ustawione warunki
nierealne w praktyce (np. odpowiednio dlugie dane wyjsciowe sa dodatkowo
hashowane np. SHA-X itp).

Sa takze sprzetowe generatory danych losowych, np. oparte na odczycie
szumow cieplnych - trzeba tylko im sie dokladnie przyjrzec przed
zastosowaniem, jak w kazdym tego typu zastosowaniu zreszta.
--
Krzysztof Halasa

do góry

W dniu 02.02.10 09:08, Jarek Andrzejewski pisze:
> On 2 Lut, 07:49, Pete<n...@n...com> wrote:
>> W dniu 01.02.10 11:16, Jarek Andrzejewski pisze:
>>
>>>> A wracając do meritum - jak w takim razie (losowe kody) druga strona
>>>> miałaby zweryfikować poprawność takiego kodu?
>>
>>> Porównać z listą przechowywaną w bazie, Watsonie :-)
>>
>> Re-we-la-cyj-ne rozwiązanie!!!
>> Że też jeszcze wszyscy inni nie wpadli na tak genialny pomysł :P
>> Nie ma to jak 100% bezpieczeństwo takiego rozwiązania
>
> Lepiej doucz się trochę z dziedziny kryptologii :-)

Nie mówimy zdaje się o szyfrowaniu a o autentykacji

> Właśnie takie
> rozwiązanie (losowy ciąg znany obu stronom) jest najbezpieczniejszym
> rozwiązaniem.

Chyba dla Jamesa 007 Bonda.
Coby mógł sobie bezpiecznie pokorespondować z M.

> Polecam Ci rozdział 9.4 z książki "Applied Cryptography, Second
> Edition: Protocols, Algorthms, and Source Code in C" Bruce Schneiera
> (jest też polskie wydanie p.t. "Kryptografia dla praktyków").

I jak się to ma do autentykacji???

--
Pete

do góry