Zabezpieczenie procesu rejestracji

[rtpm]

Jeśli API byłoby dostępne, wysyłając odpowiedniego requesta na /register można komuś zrobić psikusa, gdyż nie ma możliwości walidacji numeru telefonu, który poda się w zgłoszeniu o rejestrację.

Rozważyć więc należy możliwość dodania pola adresu IP (wiem, kwestia prywatności..), z którego poszedł request rejestracji,
co da możliwość zastosowania jakiegoś throthlingu, a w razie czego blokowania/zgłoszenia dowcipnisia. Można też korzystać z unikalnego identyfikatora urządzenia/instalacji aplikacji, ale
to jest nieweryfikowalne i wiadomo, że to co leży na urządzeniu jest raczej "jawne" i do zmanipulowania poza aplikacją.

[kgluszczyk]

W najgorszym wypadku, taka osoba dostanie kod autoryzacyjny, do którego dowcipniś nie będzie miał dostępu, a co za tym idzie nie dokończy procesu rejestracji. Myślę, że w ramach MVP dodatkowe zapezpieczenia nie są potrzebne. Nawet jeśli ktoś się pokusi o spamowanie sms-ami to aplikacja może szybciej zyskać użytkowników i rozgłos, wystarczy dobrze skomponowana wiadomość z kodem ;)

[rtpm]

Może i racja. W najgorszym wypadku wpisze losowe / nielubianych osób numery i zaspamuje je kodami weryfikacyjnymi.

Nie znam takiego rozwiązania, ale dobrym weryfikatorem jest nawiązanie przez aplikację połączenia i jakaś końcówka weryfikuje nr, z którego się dzwoni (zainicjowane przez apkę). Może takowe są.
Problem, gdy ktoś ma zastrzeżony nr. ale to pewnie mniejszość.

Wiem, że powszechność + prywatność to dwie ważne rzeczy, więc może nie warto komplikować, a martwić się, jak będzie problem.

[jakublipinski]

Fajnie, że o tym piszecie. To jest problem który mi także sen spędza z powiek. Zrobiliśmy już częściowo zabezpieczenia, które opisaliśmy tutaj: https://github.com/ProteGO-app/backend/blob/master/sms_registration.md

Będę wdzięczny za przegląd założeń i kodu który to realizuję.

Bardzo ucieszę się jeśli znajdziecie w tym jakąś lukę.

[mateuszjablonski]

Z czego wynika konieczność podania numeru telefonu? Czy jest to podyktowane jakimiś zewnętrznymi wymaganiami? W ProteGO-Safe/specs#34 postulowane jest porzucenie konieczności podawania numeru telefonu, co całkowicie wyeliminowałoby ten problem.

[rtpm]

Rzeczywiście przegapiłem dokument, w którym przedstawione są już rozwiązania. Zastanawiam się, czy w proces samej rejestracji nie zaangażować jakiejś recaptcha (Jakiś WebView, co wymagałoby modyfikacji endpointa lub tez schowania go gdzieś lub nie upubliczniania) a zastosować zwykły widok z danymi forma i tokenem captchy. Jeśli nie ma potrzeby żeby endpoint rejestracji był dostępny dla innych urządzeń itd. to można to rozważyć.

[jakublipinski]

Dzięki za wasze uwagi. Dodałem jeszcze takie zmiany #52

Widzicie jeszcze jakieś ryzyka? Czy jesteśmy zabezpieczeni przed zgadywaniem kodów?

[kfigaj]

1. Jeśli API byłoby dostępne - API nie powinno być na pewno publicznie dostępne, tylko ograniczone do applikacji mobilnych Protego. W takiej sytuacji spamowanie ograniczamy do pobranych appek. Jest to trudniejsze do zapewnienia przy otwartym kodzie. Może coś takiego byłoby pomocne? Instancje applikacji można identyfikować po https://developers.google.com/instance-id Dalej ->
2. Jeśli ktoś z jednej instancji aplikacji próbuje rejestrować wiele numerów w określonym czasie, to dostaje bana.
3. Jeśli ktoś próbuje zarejestrować z tego samego ip kolejne instancje aplikacji, albo numery instancji, który już mamy, to dostaje bana.
4. Jeśli ktoś próbuje rejestrować użytkownika bez uprzedniego zarejestrowania instancji, to dostaje bana.
5. W najgorszym wypadku, taka osoba dostanie kod autoryzacyjny, do którego dowcipniś nie będzie miał dostępu, a co za tym idzie nie dokończy procesu rejestracji. Poza instancją applikacji można by się pokusić o wysłanie jakiegoś klucza publicznego. Kod autoryzacyjny mógłby wtedy być nim szyfrowany i tylko applikacja, która ma klucz prywatny może kod odkodować i użyć. Inne kody mogą zostać zignorowane po stronie aplikacj.

Oczywiście można tego też uniknąć nie wymagając numeru telefonu :)