W dniu poniedziałek, 9 listopada 2020 22:58:58 UTC+1 użytkownik Krzysztof Halasa
napisał:
> Dawid Rutkowski writes:
>
> >> > Kiedyś czytałem gdzieś, że CVV generowane jest na podstawie numeru
> >> > karty i daty ważności. W sumie byłaby to oczywista głupota, taki
> >> > algorytm byłby złamany, jeśliby wcześniej nie wyciekł.
> >>
> >> Ktoś to wyssał z palca. Wystarczyłoby przecież wydobyć to z byle
> >> terminala. Ale niczego takiego nie ma.
> >
> > Na końcu piszesz, że terminal nie analizuje CVV2.
> > Nic z terminala nie wyciągniesz.
> > Z CVV2 tylko on-line.
>
> No ale to jest argumentacja kołowa. Tzn. tak jest, ale zakładając
> (nieprawdziwą) wersję, że kod CVV2 ma cyfrę kontrolną, terminal
> (taki, który potrafi użyć CVV2) musiałby to sprawdzać, a więc dałoby się
> to z niego wyciągnąć. No bo przecież nie myślisz chyba, że algorytm
> miałby być tak tajny, że nikt nie mógłby go używać.
>
> Przecież cyfra kontrolna nie byłaby tylko dla banku, żeby nie musiał
> sprawdzać w bazie kart. To byłoby całkiem niedorzeczne.

Nie no, czekaj czekaj.
Ja piszę o generowaniu CVC2 na podstawie numeru karty i jej daty ważności, a Ty o
sprawdzaniu ew. poprawności wpisania za pomocą cyfry kontrolnej.
To pierwsze oczywiście w terminalu nie może być, to drugie - gdyby istniało - mogłoby
być jak najbardziej, bo to nie szyfr, tylko jawny algorytm detekcji błędów.

> > Wiki twierdzi, że generowane DES na podstawie numeru karty i daty
> > ważności, klucze oczywiście zna tylko bank (klucze oczywiście różne
> > dla CVV1 i CVV2).
>
> Link? To nie jest prawda i to byłoby kompletnie bez sensu.

https://en.wikipedia.org/wiki/Card_security_code#Typ
es_of_codes
https://en.wikipedia.org/wiki/Card_security_code#Gen
eration

A czemu bez sensu?
Bezpieczniej trzymać w bazie banku komplet numer+data+CVV czy też trzymać tylko
numer+data, a CVV obliczać sobie w razie potrzeby sprawdzenia?
Obliczać oczywiście w osobnym, sprawdzonym i bardzo chronionym module.

> Może chodzi o dynamiczne CVV? Wtedy coś zbliżonego mogłoby być używane,
> aczkolwiek raczej nie w ten sposób, klucze byłyby różne dla różnych
> kart.

Dynamiczne to już na pewno musi iść jakimś kluczem, i ten klucz musi być w pamięci
karty. Do tego na pewno ATC jako seed - a w sumie w tym wypadku dlaczego nie
numer+data+ATC?
Oczywiście klucz (czy to ten sam dla symetrycznego czy do pary dla asymetrycznego)
musi być też w banku - więc tu pozostaje pytanie, czy bank ma jeden klucz dla
wszystkich swoich kart czy też każda karta ma osobny - zapewne zapisywany na etapie
produkcji, niezmienny i nie do odczytania w sposób przewidziany protokołem.

> > Więc w sumie póki klucze nie wyciekną, to można uznać za losowe.
> > Bo nie wiem, ile trzeba by mieć przykładów, żeby odtworzyć klucz.
>
> Bardzo niewiele. W obecnych czasach, gdy ludzie mają po 200 konsoli
> w domu :-) - no, to było już ładnych parę lat temu - nie byłoby to
> dobrym pomysłem. Ani nie służyłoby niczemu sensownemu.

Nie chodzi o to, ile trzeba mieć mocy obliczeniowej, żeby znaleźć klucz, którym
poprawnie przeliczysz jeden zestaw numer+data na CVV2 - i rzeczywiście będzie się ten
CVV2 zgadzał z wydrukowanym na karcie.
Tylko że to nie będzie jedyny klucz, który będzie prawidłowy dla tego przykładu - i z
dużym prawdopodobieństwem będzie nieprawidłowy dla innego przykładu.

Więc tych kluczy trzeba znaleźć miriady - i do tego mieć miriady prawdziwych
przykładów, które pozwolą odsiać klucze "prawidłowe tylko dla jednego przykładu" - aż
w końcu znajdziesz ten właściwy.

I właśnie o ten wielki zestaw prawdziwych przykładów mi chodziło - np. cała baza
banku z numer+data+CVV2.
I dlatego zapewne taka baza nie istnieje - a CVV2 za każdym razem, gdy jest potrzeba
sprawdzenia, jest generowany w banku - i dlatego nie może być losowy.

> > To po co w numerach kont czy kart czy PESELach, ISBNach czy numerach
> > dowodów osobistych (tu jest śmiesznie, numery zwiększają się tak,
> > jakby były pisane z prawej do lewej) wprowadzono liczby (czasem
> > 1-cyfrowe, ale czasem np. w systemie 11-stkowym, jak w ISBN)
> > kontrolne, jeśli nie po to, żeby się ludzie nie mylili, przepisując
> > je? Komputery się nie mylą (jedynie te z "Misia")?
>
> Właśnie po to, by się nie mylili. I właśnie dlatego w żadnych hasłach,
> PINach, CVV itd. nie ma potrzeby stosowania cyfr kontrolnych - bo
> sprawdzany jest cały ciąg.

No to też PINy - jako mające 4 znaki, cyfr kontrolnych nie mają, bo raczej się nie
pomylisz.
A nawet jak się pomylisz, to wynikiem może być tylko "wprowadź ponownie".

A jakbyś podał z pomyłką numer karty czy numer konta - a są o wiele dłuższe i łatwiej
się pomylić - i nie byłoby cyfry kontrolnej, to jest szansa, że podany numer karty
czy konta by istniał - i poszłoby obciążenie na inną kartę czy przelew na inne konto.

Samo CVV, jako trzycyfrowe, pewnie nie ma cyfry kontrolnej dla "samego siebie".
Ale może mieć dla 18-cyfrowej sekwencji numer karty+2 pierwsze cyfry CVV.
Pewnie jednak tak nie jest, bo podanie błędnego CVV nie może spowodować, że wskazane
zostanie inne prawidłowe konto.

> Swoją drogą, nie pamiętam komputera w Misiu. Ale nieważne.

Inkasent z elektrowni.

> Najbliżej "cyfry kontrolnej" w hasłach jest skrót kryptograficzny, ale
> wtedy nie przechowuje się całego hasła. Z PINem ani CVV* tak się nie da.

Tzn. co, nie da się "skrócić kryptograficznie" PINu czy CVV i tak ich trzymać w
bazie?
Przecież się da, ważne tylko, by ten "skrót" nie skracał, a szyfrował - czyli żeby
jego długość była większa niż PINu czy CVV - i oczywiście żeby algorytm gwarantował,
że dla dwóch różnych PINów nie powstanie taka sama wartość zaszyfrowana.

> >> Wyjdzie - z prawdopodobieństwem 99% (czy jakoś tak, zależnie od tego,
> >> w jaki sposób ktoś ma się pomylić).
> >
> > Lepszym, algorytm eliminuje najbardziej prawdopodobne błędy, np.
> > wszystkie pomyłki jednej cyfry.
>
> Dlatego napisałem "czy jakoś tak", bardziej myślałem nie o prawdziwej
> pomyłce (skomplikowana sprawa, wymagająca analizy możliwych błędów i ich
> prawdopodobieństwa), a raczej o wymyślaniu numeru z sufitu.

A, z sufitu to oczywiście przejdzie z prawdopodobieństwem 1%.
Ale to przecież nie było robione w celu zapobiegania podawaniu numerom z sufitu,
tylko zapobiegania pomyłkom, a naciskiem na te najbardziej prawdopodobne.
Tylko jak ktoś chce podać fałszywy PESEL czy numer konta, to nie będzie go zgadywał,
tylko jednak sprawdzi w wiki, jak się tą liczbę kontrolną oblicza.
W przypadku PESEL nawet nie musi sam liczyć - wystarczy wejść na stronę zakładania
konta w banku i tam mądry komputer sam wskaże, czy numer jest poprawny czy też nie -
wystarczy wiedzieć, że ostatnia cyfra jest kontrolna i ją ew. zmieniać - max. 10
prób.
Jeszcze "lepsze" strony sprawdzą, czy podany PESEL zgadza się z podaną datą urodzenia
(oczywiście też wymyśloną), a nawet czy zgadza się z płcią.

Zaś to, że prawdopodobieństwa możliwych pomyłek zostały zbadane przy opracowywaniu
algorytmu generacji liczby kontrolnej - to chyba można domniemywać. No chyba że
zakładasz, że wszystko w informatyce jest robione przez dzieci neostrady...