Czy ten algorytm rejestacji konta ma jakies powazne bledy?

0

Chcialem spytac czy ten pomysl na zabezpieczenie konta jest dobry czy ma jakies mega dziury ktore przegapilem.

Program aplikacja na telefonie wymaga rejestracji uzytkownika ktory to wykonuje wlasnorecznie.

Wszystkie wywolania na moj API sa po https. A zeby zalozy konto trzeba wywoalc dwie funkcje.

Algorytm dzialania mam taki:

  1. Otwarcie aplikacji i ona do zaloze ia konta
  2. Pojawia sie opcja wpisania email,haslo i ponownie haslo
  3. Wysylam po ssl te 3 dane do serwera.
  4. Serwer losuje klucz i z tego klucz plus tych moich 3 danych oblicza skrot i zapmaietuje jako klucz A
  5. Serwer odsyla do aplikacji informacje ze wstepne zakladanie konta jest ok i wysyla mi ten swoj wylosowany klucz
  6. Aplikacja oblicza skrot tak samo jak aplikacja i odsyla zwrotke.
  7. Jesli obliczone skroty sie zgadzaja to serwer zaklada konto jesli nie wyswietla blad

W kluczu wyslanym od serwera mozna zakodowac jakim algorytem mamy ibliczyc skrot

Druga sprawa ze jezeli jest serwis i zarejestruje sie milion uzytkownikow a polowa z nich to sztuczne konta to te konta spowoduja ze plik bazy danych bedzie duzy bo nawet jak sie usunie dane to plik sie nie zmniejsza zeby go nie defragmentowac.

I pomyslalem ze moze zrobic dwoe bazy jedna taka przejsciowa z ktorej po aktywacji konta dane przechodza do tej wlasciwej a przejsciowa ma co jakis czas kasowane pliki z tabelami i nigdy nie zasyfi sie danymi np na 300giga

Czy dobrze mysle w obu przypadkach?

0

Algorytm jest trochę bez sensu i nie bardzo rozumiem do czego on ma niby służyć. Ten klucz ma być tylko do potwierdzenia konta czy ty chcesz jakeiś TOTP tam postawić? Jeśli tylko do potwierdzania to kombinujesz niesamowicie. Wygeneruj klucz, wyślij link potwierdzający z tym kluczem, a w bazie stwórz wpis w tabeli gdzie kluczem są klucze potwierdzające. Ta tabela np. raz dziennie usuwa wszystkie wpisy starsze niż X. Jeśli ktoś kliknie w link i w tabeli masz wpis z tym kluczem to potwierdzasz konto i wrzucasz dane do prawdziwej bazy. Nie rozumiem zupełnie po co chcesz wysłać userowi dane do wyliczenia skrótu samodzielnie.

0

Chodzi mi o to zeby nie dodawac uzytkownika ktory nie wyliczy skrotu bo jak np ktos sprawdzi gzie jest api i zrobi petle to zalozy mi np 100 niepotwierdzonych uzytkownikow. A chce sie przed tym zabezpieczyc

0

Ale co ma piernik do wiatraka? o_O

  1. User podaje dane i wysyła.
  2. Zapisujesz dane w tymczasowej tabeli razem z wyliczonym kluczem potwierdzenia.
  3. Odsyłasz klucz potwierdzenia userowi żeby kliknął link
  4. User klika, ty na stronie widzisz że jest potwierdzenie z danym kluczem, sprawdzasz w tymczasowej tabeli czy taki istnieje, jeśli tak to przenosisz dane do właściwej tabeli, jeśli nie to olewasz.
  5. Tymczasowa tabela co np. 24h usuwa wszystkie wpisy starsze niz 1 dzień.
  6. Profit.

Nie widzę w jaki sposób odsyłanie kawałka klucza i liczenie go w aplikacji mobilnej cokolwiek zmienia. Oprócz tego oczywiscie że robisz dziurę w zabezpieczeniu bo każdy wie jak tworzysz klucz potwierdzajacy ;]

0

A czy czyszczenie tej tabeli tymczasowej ktora ma na przyklad 10 tys rekordow spowoduje ze plik bazy danych sie zmniejszy ? Jesli tak to moje rozwiazanie jest bez sensu jeśli nie to włsnie chcialem uniknac tego zeby ktos zasypal mi tabele sztucznymi adresami ktore tylko zwieksza mi pojemnosc bazy danych

0

Ta tymczasowa baza to moze nawet byś jakiś HSQL albo SQLite w pliku i każdego dnia zapisujesz dane w nowym pliku a stary kasujesz. Przecież to od ciebie zależy!

Mam wrażenie że szukasz problemu tam gdzie go w ogóle nie ma. Poza tym email+hasło nawet z limitem po 1000 znaków to jest raptem 2kB danych. 10k rekordów to jest raptem 20 MB danych...

Nie widze zresztą jak niby działa to twoje "zabezpieczenie". Jeśli ktoś zgodnie z moim pomysłem moze kliknąć w link żeby potwierdzić konto to może też spokojnie wygenerować sobie ten twój klucz i potwierdzić konto. Gdzie ty widzisz różnicę?

0

A czy czyszczenie tej tabeli tymczasowej ktora ma na przyklad 10 tys rekordow spowoduje ze plik bazy danych sie zmniejszy ?

Najczęściej tak, ale zależy to od silnika bazy danych. Szukaj pod hasłami "vacuum" (postgres) albo "optimize" (mysql).

0
Shalom napisał(a):

Ta tymczasowa baza to moze nawet byś jakiś HSQL albo SQLite w pliku i każdego dnia zapisujesz dane w nowym pliku a stary kasujesz. Przecież to od ciebie zależy!

Mam wrażenie że szukasz problemu tam gdzie go w ogóle nie ma. Poza tym email+hasło nawet z limitem po 1000 znaków to jest raptem 2kB danych. 10k rekordów to jest raptem 20 MB danych...

Nie widze zresztą jak niby działa to twoje "zabezpieczenie". Jeśli ktoś zgodnie z moim pomysłem moze kliknąć w link żeby potwierdzić konto to może też spokojnie wygenerować sobie ten twój klucz i potwierdzić konto. Gdzie ty widzisz różnicę?

Odpisuje tak tylko żeby naprostować swoje myślenie. Ty mówisz o zdarzeniu które ma miejsce już po moim zabezpieczeniu. Moje zabezpieczenie jest jeszcze przed wrzuceniem rekordu do bazy i wyslaniem adresu emaila. Zabezpieczenie jest więc takie:

  1. Podajesz dane zeby sie zarejestrowac z aplikacji z fona
  2. serwer bierze dane losuje klucz i oblicza skrot
  3. serwer wysyla wylosowany skrot zeby twoja aplikacja obliczyla skrot
  4. jesli twoja aplikacja obliczy skrot i beda takie same to serwer doda twoj email i klucz aktywacyjny w ktory dopiero
    klikasz zeby aktywowac konto. Wiec moje zabezpieczenie dziala przed tym wszystkim.
  5. cos jak token do logowania do bankow tylko zamiast token masz aplikacje
0

To ma zabezpieczac przed uzywaniem API bez aplikacji hahaha :D I mówisz to o aplikacji którą user będzie miał zainstalowaną? I co niby ma mu przeszkodzić w jej deasemblacji i reversowaniu algorytmu?
Żeby daleko nie szukać, poczytaj sobie np.
https://github.com/p4-team/ctf/tree/master/2015-09-16-csaw/re_300_ftp
https://github.com/p4-team/ctf/tree/master/2015-09-16-csaw/web_500_weebdate
;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1