do czego służy token lub lista haseł jednorazowych, wiemy...
używamy ich do zatwierdzania przelewów w internetowym
kanale dostępu do rachunku bankowego

ja chcę zadać pytanie dotyczące poprawności językowej

czy token lub lista haseł jednorazowych jest instrumentem?
urządzeniem? narzędziem? chodzi mi o określenie, które będzie jednocześnie poprawne
językowo i nie-sprzeczne z językiem ustawy prawo bankowe i
regulaminów bankowych

--

zwyklyklientwieluzwyklychbankow1@op.pl pisze:

do czego służy token lub lista haseł jednorazowych, wiemy...
używamy ich do zatwierdzania przelewów w internetowym
kanale dostępu do rachunku bankowego

ja chcę zadać pytanie dotyczące poprawności językowej

czy token lub lista haseł jednorazowych jest instrumentem?
urządzeniem? narzędziem? chodzi mi o określenie, które będzie jednocześnie poprawne
językowo i nie-sprzeczne z językiem ustawy prawo bankowe i
regulaminów bankowych

Jest metodą uwierzytelnienia.

wer

Dnia Tue, 29 Dec 2009 07:06:09 +0100, bofh@nano.pl napisał(a):

Jest metodą uwierzytelnienia.

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 ;)


--
xbartx - Xperimental Biomechanical Android Responsible for Thorough Xenocide

In pl.hum.polszczyzna xbartx <bart@hashzero.net> wrote:

Dnia Tue, 29 Dec 2009 07:06:09 +0100, bofh@nano.pl napisał(a):

Jest metodą uwierzytelnienia.

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.

R.
--
Uniwersytet katolicki to oksymoron udający tautologię.

On 30 Sty, 16:19, Rafał Maszkowski <r...@icm.edu.pl> wrote:

In pl.hum.polszczyzna xbartx <b...@hashzero.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.

--
pozdrawiam,
Jarek Andrzejewski

W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:

On 30 Sty, 16:19, Rafał Maszkowski<r...@icm.edu.pl>  wrote:

In pl.hum.polszczyzna xbartx<b...@hashzero.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

On 30 Sty, 20:41, Pete <nob...@nowhere.com> wrote:

W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:

> On 30 Sty, 16:19, Rafał Maszkowski<r...@icm.edu.pl>  wrote:
>> In pl.hum.polszczyzna xbartx<b...@hashzero.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

W dniu 01.02.10 11:16, Jarek Andrzejewski pisze:

On 30 Sty, 20:41, Pete<nob...@nowhere.com>  wrote:

W dniu 30.01.10 19:15, Jarek Andrzejewski pisze:

On 30 Sty, 16:19, Rafał Maszkowski<r...@icm.edu.pl>    wrote:

In pl.hum.polszczyzna xbartx<b...@hashzero.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

On 2 Lut, 07:49, Pete <nob...@nowhere.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

Jarek Andrzejewski <ptja.pl@googlemail.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

On 2 Lut, 16:19, Krzysztof Halasa <k...@pm.waw.pl> wrote:

Jarek Andrzejewski <ptja...@googlemail.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

Jarek Andrzejewski <ptja.pl@googlemail.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

W dniu 02.02.10 09:08, Jarek Andrzejewski pisze:

On 2 Lut, 07:49, Pete<nob...@nowhere.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

<bofh@nano.pl> hhc68e$vgk$2@news.supermedia.pl

Jest metodą uwierzytelnienia.

Token jest metodą? Raczej nie. Ani to Metoda, ani Cyryl. ;)
Narzędzie? OK. Urządzenie -- tym bardziej. Ale metoda -- nie.


   metoda ż IV, CMs. ~odzie; lm D. ~od

   1. <<świadomie i konsekwentnie stosowany sposób postępowania
      dla osiągnięcia określonego celu; zespół celowych czynności
   i środków>>

Token jest sposobem lub czynnością? Na pewno nie.

   Metoda wychowania dziecka.

   2. <<sposób naukowego badania rzeczy i zjawisk; ogół reguł
      stosowanych przy badaniu rzeczywistości>

Token ma być sposobem czy regułą?

   Metoda naukowa.
   Metoda badań archeologicznych.
   z gr.

Coś tu nie tak. :)

-=-

Korzystanie z tokena czy zdrapek może być metodą,
ale sam token czy zdrapka -- nie. :) IMO rzecz jasna. :)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.'    eneuel@@gmail.com    '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

A dlaczego nie pasuje ci określenie

.... lista haseł jednorazowych....

?

--
(tekst w nowej ortografi: ó->u, ch->h, rz->ż lub sz, -ii -> -i)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. reforma.ortografi.w.interia.pl

Użytkownik "Stokrotka" <ortografia1@autograf.pl> napisał w wiadomości news:hhcieh$5oe$1news.onet.pl...

(tekst w nowej ortografi: ó->u, ch->h, rz->ż lub sz, -ii -> -i)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,

Nawyk nie nawyk, ale na pierwszy rzut oka moge stwierdzic, czy mam do czynienia z normalnym czlowiekiem, czy z idiota.

Pozdrawiam
SDD

zwyklyklientwieluzwyklychbankow1@op.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ą).

pozdrawiam
--
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

On 2010-01-11 03:18, Marcin Gryszkalis wrote:

zwyklyklientwieluzwyklychbankow1@op.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_%28informatyka%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.