Optymalizacja częstego odświeżania kodu QR

Hej

Mam dylemat jak zrealizować change requesta od klienta. Opiszę ogólnikowo jaki jest problem. Mamy urządzenia na którym użytkownikowi zaprezentowany jest kod QR. Klient chce żeby ten kod był odświeżany co sekundę ze względu na politykę bezpieczeństwa. Problem polega na tym, że kod QR oparty jest o stringa który serwer dostaje od zewnętrznego API odpytując się RESTowo. Tenże endpoint RESTowy zwraca oprócz tego stringa informację czy ktoś zeskanował kod QR który opierał się na konkretnym tokenie czy nie. Token jest częścią stringa który służy do generowania kodu QR, jest stały przez określony czas (powiedzmy 30 sekund) a oprócz tokenu jest też doklejany jakiś zmienny suffix który co sekundę jest inny dając unikalny string a następnie kod QR. Jeśli endpoint zwróci info, że ktoś zeskanował kod QR zawierający konkretny token to przestajemy odpytywać.

Wydaje się to ciężkie pod względem ilości requestów które trzeba obsługiwać. Urządzeń może być sporo a interwał sekundowy to jest dość dużo. Macie jakiś pomysł jak to zrealizować efektywnie? Cron czy coś bardziej finezyjnego?

Co znaczy sporo urządzeń? 10, 100, 1000, 1000000?
Ale po co odświeżać jak nikt nie zeskanował? Trzeba byb odwrócić komunikację i wypychać dane na te urządzenia które muszą być odświeżone po zeskanownaiu tokena. Możesz to.robic na jakimś sockecie.
Jak koniecznie chcesz coś odpytywać to postaw redisa w nim trzymaj dane które będzie updatowal po zeskanowaniu tokena. I tp da radę obsłużyć naprawdę dużo.

Socket > połączenia http, jakiś cache na tokeny. Otwartą kwestią pozostaje pingowanie serwisu zwracającego te stringi i status tokenu bo odpytywanie w kolko co sekundę o status tokenu przy wielu tokenach może Ci zabić tę usługę. Zmiany w niej są mozliwe aby to ta restowa usługa strzelała do Ciebie gdy status tokenu się przekręci?

Inna sprawa, że biznes nierzadko oczekuje cudów nie mając świadomości, że coś z róznych względów może być np. turbo nieoptymalne/trudne/nieopłacalne w implementacji.
Dobrze jakbyś te wymagania skonsultował z jakimś architektem w porjekcie/organizacji oraz właścicielami usługi zwracającej tokeny/stringi.

Napisałeś, że istotny jest token i jest on ważny przez 30 sekund. Z jakiego powodu nie można na podstawie danych otrzymanych z serwera co 30 sek. po stronie urządzenia co jedną sekundę generować kodu QR ?

S4t napisał(a):

Co znaczy sporo urządzeń? 10, 100, 1000, 1000000?
Ale po co odświeżać jak nikt nie zeskanował? Trzeba by....

Zgadzam się, jest coś dziwnego w idei początkowej

Częsta zmiana QR zapewne ma pozwolić na jednoznacznie wykrycie, który użytkownik wcześniej zeskanował kod.
Mogę sobie wyobrazić celowy atak. Ktoś skanuje kod QR przy pomocy smartfona. Staję obok i zakłócam działanie sieci GSM. Następnie skanuję ten sam kod.

Jeśli będzie co sekundę odświeżany, to zanim ktoś zeskanuje i wejdzie w to, to już będzie nieaktualny (BTW a co jeśli ktoś zrobi zdjęcie kodu QR "na później"?).

Poza tym samo przesłanie tego kodu na serwer może trwać więcej niż sekundę.

W ogóle do czego ten QR ma być?

Odpowiadając na pytania dlaczego tak często odświeżany jest kod QR jest to wymuszone regulacjami bezpieczeństwa aby nie mogło dwóch użytkowników zeskanować tego samego kodu. Urządzenia to nie są prywatne telefony komórkowe tylko coś innego. Nie mogę zdradzać szczegółowych informacji ze względu na NDA. Ale właśnie @P2420 mniej więcej wychwycił o co tu chodzi. Ogólnie @P2420 zadal dobre pytanie dlaczego nie zaszyć generowania kodu QR na samym urządzeniu i pytać o nowy token na przykład co 30 sekund. Nie może tak być bo składową stringa z którego generowane jest kod QR jest coś ala SecretKey i nie może on być udostępniany finalnym klientom czyli urządzeniem na których przentowany jest kod QR. Jest to narzucona regulacja z góry. Dlatego właśnie kombinuje jak to wszystko rozegrać optymalnie po stronie serwerowej.

marlukk napisał(a):

Odpowiadając na pytania dlaczego tak często odświeżam jest kod QR jest to wymuszone regulacjami bezpieczeństwa aby nie mogło dwóch użytkowników zeskanować tego samego kodu.

A jakby w jednym kodzie QR umieścić ileś docelowych kodów?

Wtedy kilku użytkowników mogłoby zeskanować ten sam kod QR, a serwer by już sobie wybrał, który będzie właściwy/jeszcze nieużyty. Czy może pomijam jakąś ważną część tego, jak to ma działać?

Piszesz, że "SecretKey" nie może być udostępniany klientom a jednak jest wysyłany. Coś tu się nie zagradza. Czy rozwiązanie ma być odporne na zhakowanie urządzenia czy nie jest to konieczne ?

Wyświetlanie kodu co 1 sekundę wydaje się maskować inny problem.

1. Z zewnętrznego serwisu przychodzi tokenA ważny X czasu.
2. Urządzenie#1 wyświetla QR1(tokenA,sufix123)
3. Urządzenie#2 wyświetla QR2(tokenA,sufix456)

Przyjmijmy, że:

• lecą 2 requesty wynikające z równoczesnego skanowania różnych QR codów z tym samym tokenem
• masz 2 instancje serwisu realizujące "skanujQRCode"
• requesty lecą do różnych instancji

Skąd wiesz, że "tokenA" został już użyty?

• Urządzenie dostaje base token raz na dobę (może być częściej, albo rzadziej...)
• Urządzenie wylicza qrcode(hmac(deviceSpecificToken, timestamp/1000))
• użytkownik skanuje qr code i jak rozumiem wysyła go do serwera
• serwer sprawdza, czy w ciągu osatatnich 30 sekund dało się wygenerować taki qr code
• zapisuje to sobie w pamięci na 30 sekund, żeby sprawdzić, czy nie jest to ponowne użycie

W architekturze rozproszonej, trzeba sobie wyznaczyć jakiś singleton w postaci pojedynczego mikroserwisu, albo redis'a do pamiętania listy ostatnio użytych kodów.

Jeśli urządzeń jest dużo to istotna jest odpowiedz na takie pytania:
Jakie nakłady należy ponieść aby odczytać program zawarty w danym urządzeniu ? Jakie potencjalnie zyski może przynieść odczytanie i analiza tego kodu w odniesieniu do całego rozwiązania?
Rozumiem, że obawa przez lokalnym generowaniem QR co 1 sek. na podstawie rzadko przesyłanego "SecretKey" jest związana z tym zagadnieniem.
Często dokłada się do sprzętu mały specjalizowany układ kryptograficzny, Kosztuje poniżej 1EUR. Jest jednokrotnie programowany i wykonuje np. szyfrowanie/deszyfrowanie AES128. Producent gwarantuje, że w nie ma znanych metod odczytania zawartego w nim kodu. Mając takie sprzętowe zabezpieczenie pozyskanie firmware urządzenia nie jest groźne.

piotrpo napisał(a):

...

W architekturze rozproszonej, trzeba sobie wyznaczyć jakiś singleton w postaci pojedynczego mikroserwisu, albo redis'a do pamiętania listy ostatnio użytych kodów.

W rozproszonej jest okazja do pewnych hazardów na wspomnianym przez Ciebie serwerze / serwisie, słusznie to podkreśliłeś, ale i tak jest milion razy mniejsza niż w pomyśle brutal force zaoie... odświeżania obrazka na kliencie

Jak na zadęcie formalne (umowy NDA itd), pachnie niemałym zespołem / korpo / stadem architektów - to idea obrazka jest wg mnie "jak się małemu Jasiowi wydawało"

Ktoś tu powiedział "autobus" ... obie są tak samo czułe na zanik internetu, ale i tak tam jest słowo "zalogowanie" czyli zakładamy, bez netu i tak nic się nie da zrobić

Ogólnie tu jest problem XY i nie ma sensu już podpowiadać autorowi. Za dużo niewiadomych i zaproponowane rozwiązanie wydaje się bezsensu.
Rozumiem NDA ale można napisać wszystkie wymagania i jak to działa za pomocą jakichś analogi...