Autor Wątek: Utrudnienie dostępu osobom nieupoważnionym.  (Przeczytany 4976 razy)

Offline Tinekk

  • Użytkownik

# Luty 10, 2014, 02:11:09
Nie jestem pewny czy wybrałem dobry dział, ale..
Zamierzam zablokować dostęp do swojej aplikacji, udostępniając go tylko tym którzy ją zakupią.
Wiem że celu w 100% nie osiągnę, ale chciał bym to zrobić najlepiej. Moim pomysłem jest powiązanie "fingerprintu" z e-mailem podanym przy zakupie. Użytkownik otwierający aplikacje po raz pierwszy podaje swój e-mail (względnie z hasłem/kluczem) wtedy uzupełniam odpowiedni rekord "fingerprintem" którym była by jakaś (pół)unikalna informacja o komputerze np. adres mac karty sieciowej. Przy następnych uruchomieniach sprawdzam tylko czy dane się zgadzają. Może nie działam wg. zasady KISS, ale mam czas, chęci, oraz męczy mnie ciekawość. Jak wy byście to rozwiązali?

Druga kwestia związana z tematem, jak najbezpieczniej łączyć się z bazą danych (c#). Jeżeli login/pass będą hardcoded to można się do nich dostać (raczej) bez większego trudu.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline PsichiX (ΨΧΞ)

  • Użytkownik
    • PsichiX Website

  • +2
# Luty 10, 2014, 02:29:45
dostep do bazy: skrypty php ktore wyciagaja dane z bazy i zwracaja w jsonie. wywolywanie api przez http

Offline ShadowDancer

  • Redaktor

  • +2
# Luty 10, 2014, 08:04:53
Co jak zmienię kartę sieciową?

Offline Xender

  • Użytkownik

# Luty 10, 2014, 10:00:05
@OP - Trzymać logikę biznesową aplikacji na swoim serwerze, a klientowi dać tylko klienta jako fronend - to byłoby całkiem skuteczne rozwiązanie licencjonowania. Oczywiście nie każdy klient zgodzi się na trzymanie danych "w chmurze".

Dopóki nie zdradzisz nieco więcej szczegółów, to jedyne, co tu się wydarzy, to dyskusja o DRM. A to już bardzo stary i wyeksploatowany temat.

Aczkolwiek patrząc na drugą część pytania...:

dostep do bazy: skrypty php ktore wyciagaja dane z bazy i zwracaja w jsonie. wywolywanie api przez http
Srsly? We need to go deeper? I do tego jeszcze w PHP - gorzej nie można było?

Można prościej - każdy klient bazy danych ma w niej osobne konto, ze sowim loginem i hasłem, które ma dostęp tylko do swoich danych.

Konto w bazie powiązane z licencją wydaje się tu być oczywistym wyborem.

Offline ArekBal

  • Użytkownik

  • +1
# Luty 10, 2014, 11:39:12
Http będzie - biorąc pod uwagę stan dzisiejszych frameworków MVC - prostsze i potężniejsze.

Offline Xion

  • Redaktor
    • xion.log

  • +6
# Luty 10, 2014, 14:47:01
Cytuj
Srsly? We need to go deeper?
Że co proszę? Backend gadający z bazą danych i wystawiający API dla frontendu (dowolnego rodzaju) to stary i sprawdzony patent, a  jego zalety - od security po skalowalność - są oczywiste. To co zasługuje na "Srsly?" to twoje wariackie pomysły tworzenia aplikacji klienckiej która bezpośrednio kontaktuje się ze zdalną bazą danych.

Offline Tinekk

  • Użytkownik

# Luty 10, 2014, 15:08:47
Co jak zmienię kartę sieciową?
Ogólnie założenie było takie (czekałem na podobną odpowiedź) że licencja jest na jeden komputer - jej koszt rzędu 5zł za miesiąc nie jest mega duży, zresztą zawsze można zmienić wpis w bazie danych, tak aby jedna licencja była odpalana (w założeniu że nie ciągle na zmianę) na innym komputerze - można spokoje zrobić skrypt który będzie zezwalał na zmianę fingerprintu raz na miesiąc. Wolał bym aby użytkownicy mogli korzystać ze swojej licencji na każdym z ich komputerów jednak znam na tyle target że wiem, że jedna osoba kupi i da 20 następnym.

ΨΧΞ,Xender
Aplikacja nie potrzebuje danych zewnętrznych, właściwie jak by się uparł mógł bym skrypty tworzone przez użytkownika trzymać na chmurze zamiast na lokalnym pc i wtedy faktycznie by potrzebowała. Ale jest to zbędny feature, który dodatkowo uniemożliwia sharowanie skryptów między użytkownikami.
Na serwerze zamierzałem trzymać w jednej tabeli dane użytkowników w formacie:
-email
-haslo(opcjonalnie)
-fingerprint
-data ważności konta
Osobne konto dla każdego użytkownika żeby trzymać tylko te 3-4 informacje to raczej nie zbyt rozsądne.

Myślałem o skrypcie w PHP, zwracał by on wtedy true/false zależnie od tego czy użytkownik może się zalogować. Właściwie skrypt PHP broni mnie tylko przed tym żeby nie ujawnić haseł do bazy danych, a nie przed tym aby utrudnić wejście do aplikacji, o ile się dobrze orientuje (nigdy się tym nie bawiłem) można runtime zmienić zmienną w if-ie (lub zmienić adres do bloku).

Najrozsądniejszym rozwiązaniem więc było by trzymanie jakichś kluczowych funkcji na zewnętrznym serwerze, np dzięki WCF.
 
Dopóki nie zdradzisz nieco więcej szczegółów,...
Nie będę się rozpisywać na ten temat bo to właściwie nic nie wnosi nowego do temat, dlatego jak interesują cie jakieś kluczowe informacje to pytaj.

Offline Joker

  • Użytkownik

# Luty 10, 2014, 15:13:50
Jeżeli abonament ma być tak niski to wydaje mi się że wystarczy sprawdzanie w zwykłej bazie danych czy klucz x istnieje i czy nie został aktywowany 2 razy, jak tak to włącz program, jak już aktywowany - wyświetl komunikat. Plus zabezpieczenie typu gdy internet wyłączony na czas startu programu - program nie działa. Myślę że takie proste zabezpieczenie się sprawdzi, i nikt tego nie będzie nawet próbował złamać.

Offline Xenox93

  • Użytkownik

# Luty 10, 2014, 15:19:50
Dokładnie, tak jak Xender napisał ;) Tylko, że nie jestem za 100% wykorzystaniem chmury, choć można innym dać taką możliwość. Nie wiem czy taki pomysł kiedykolwiek był, ale ostatnio zastanawiałem się nad pogodzeniem prywatności i zalet jakie oferuje chmura, w rezultacie doszedłem do pewnego wniosku, nie wiem czy można to nazwać chmurą, ale hybrydą na pewno ;)

Otóż, konsument twojego produktu płaci za niego. Ty mu jakoś dajesz możliwość zarejestrowania się. Następnie pobiera klienta, który łączy się z serwerem, chmurą(?) :] Następnie użytkownik aplikacji renderuje UI itp, ale logika jest na serwerze, np. użytkownik naciśnie przycisk to wszystko sprawdzane jest na serwerze, dopiero serwer wydaje polecenie do klienta, ten odpowiednio reaguje na pakiet, polecenia i wywołuje akcję ;) Można dać większą swobodę i część logiki pozostawić klientowi. Do tego, dane mogą być trzymane na komputerze konsumenta, wtedy ma poczucie prywatności. Aha, tylko głupotą byłoby otwieranie pliku projektu, który znajduje się na komputerze użytkownika, w ten sposób, że wysyłasz plik na serwer. Tym musi zając się klient, to u niego parsowany jest plik.
To jest połączenie prywatności z najlepszym rozwiązaniem licencjonowania, ofc, najlepsze wśród sposobów, które polegają na połączeniu z internetem, bo co jeśli internet padnie lub zwolni? Stosowanie DRM mija się z celem i chyba nie jest już to takie modne, choć można ten sposób zabezpieczeń jeszcze spotkać.

Ale to jest lepsze rozwiązanie od twojego, bo:
1. Co jeśli użytkownik zmieni adres e-mail lub go zapomni? Musi kupić produkt od nowa? To jest najlepszy sposób zarabiania pieniędzy i tak też się praktykuje, ale to jest domena ludzi bezwzględnych, tyranów, którzy uważają, że jeśli chcesz poczuć się VIP'em musisz się dostosować do niego. Ale skoro kupienie licencji na dodatkowy komputer wynosi 5 zł, to nie jest źle ;) Ale co jeśli aplikacja stanie się popularna, wtedy żebyś nie wpadł na te same tory co większość, że kolejna licencja wynosi 500 lub 1 000 zł ;P

2. Adres MAC karty sieciowej to zły pomysł. ShadowDancer podał dobry przykład, a nawet co jeśli zmienię adres karty? Tak samo sytuacja wygląda z adresem IP ;)

Ale jest jedno rozwiązanie, które warto chyba zastosować, czyli liczba osób zalogowanych na jedno konto. Bo co jeśli zastosowałbyś tak restrykcyjne zasady, a nie stałoby nic na przeszkodzie, żebym wpadł do kumpla na piwo, pobrał aplikację/klienta, zalogował się jako ja i mógłby jednocześnie korzystać on i ja ;P Na ogół takie sytuacje mają miejsce, co mnie martwi, bo kupując legalnie grę, produkt i weryfikując autentyczność produktu, okazuje się że mam problemy, natomiast kumpel, który pobrał crack'a lub podałem mu moje konto lub dostał od kogoś innego, może korzystać z usługi bez płacenia :/

PS. Część osób już mnie wyprzedziła :]
« Ostatnia zmiana: Luty 10, 2014, 15:24:14 wysłana przez Xenox93 »

Offline Tinekk

  • Użytkownik

# Luty 10, 2014, 16:30:27
Liczba osób zalogowanych na jedno konto - w tym wypadku nie sprawdzi się bo raczej aplikacja będzie odpalana raz na jakiś czas, mało kto będzie miał włączoną 24/7 chociaż wiem że i tacy się znajdą.

Target jest b.mały, nie zamierzam zarobić milionów i jestem świadom że zysk może pewnie nie przekroczyć  1000zł. Ale na czas który poświęciłem na stworzenie jest to i tak dobry wynik ;)
A nawet i z 500zł bym się ucieszył :s

Może trochę szaleje, tak jak Joker piszę, myślę że nie będzie dużo chętnych do crackowania. Ale jak raz crack wpadnie w sieć to mój przychód maleje do 0zł/miesiąc :) nic nowego nie wymyśle już aby wypuścić drugą wersje lepiej zabezpieczoną. Sprawa wygląda tak, że potencjalni klienci zazwyczaj dobrze się znają między sobą, co zmusza mnie do pomyślenia nad lepszym zabezpieczeniem aby uniknąć sytuacji gdzie jedna osoba kupuje a reszta dostaje za darmo - nawet jak by ta jedna osoba wykupiła dożywotnią licencje :s
Tak jak już wspomniałem, mam czas i chęci, jeżeli zrobię to lepiej - nauczę się czegoś co może mi się w przyszłości przydać.

To czy użytkownik zapomni adresu e-mail to już jest jego sprawa :) Może okrutne stwierdzenie ale to tak jak bym sprzedawał w sklepie
[obojętne jaki - w cenie ok. 5zł] produkt i martwił się czy konsumentowi nie wypadnie on czasem z siatki zanim dojdzie do domu.

Czyli faktycznie trzeba będzie pomyśleć o czymś co będzie działać na zasadzie aplikacja-render serwer-logika.

Zastanawiam się teraz czy faktycznie skrypty PHP były by gorsze od osobnego serwera. Daje mi to że nie muszę babrać się z stawianiem serwera, pilnowania go. A zostawiam parę skryptów na www, które szybko mogę naprawić, przenieść na inny hosting.

Offline Xirdus

  • Redaktor

# Luty 10, 2014, 16:43:45
Kilka kluczowych funkcjonalności, bez których aplikacja nie może działać, zrób w chmurze, a resztę jak np. zarządzanie projektem zostaw po stronie klienta, tak żeby jak najmniej danych trafiało w chmurę. Ciężko doradzić cosś konkretnego nie wiedząc nawet do czego ta aplikacja służy.

Offline Xender

  • Użytkownik

# Luty 10, 2014, 23:51:59
Jeśli aplikacja nie potrzebuje do działania danych z Twoich serwerów i nie jest ściśle związana z internetem, to implementowanie kluczowych funkcjonalności na zdalnym serwerze jest utrudnianiem użytkownikowi życia w wypadku np. awarii netu.

Do czego w ogóle ta baza danych? Tylko do sprawdzania licencji, czy jednak aplikacja czegoś z nie potrzebuje?
Co do dostępu - hardcode hasła w aplikacji - nie powinieneś tego nawet rozważać.
User bazy danych per licencja - zaproponowałem to wcześniej, chociaż nie wiem, czy istnieją rozwiązania, które pozwolą zrobić to wystarczająco bezpiecznie. Xion może mieć tu większe doświadczenie, więc to może nie był dobry pomysł.
Frontend na serwerze - OK, ale porządnie zaimplementowany. I PHP niekoniecznie jest najlepszym pomysłem.

Offline Tinekk

  • Użytkownik

# Luty 11, 2014, 15:40:28
Xender, aplikacja będzie miała sens tylko gdy jest włączony internet, więc awaria internetu nie działa na niekorzyść użytkownika. Zaimplementowałem już całe logowanie. Zostało mi przeniesienie kluczowych funkcji liczących do skryptów. Też myślę że to chyba najlepsze rozwiązanie.
Baza wykorzystywana jest tylko do trzymania licencji.

Jedyna kwestia którą mógł bym podać jeszcze dyskusji to wady i zalety PHP w tym wypadku. Zawsze można wszystko szybko przepisać, ale czy faktycznie jest sens?

Offline Xirdus

  • Redaktor

# Luty 11, 2014, 16:11:31
Jedyna kwestia którą mógł bym podać jeszcze dyskusji to wady i zalety PHP w tym wypadku. Zawsze można wszystko szybko przepisać, ale czy faktycznie jest sens?
PHP jest kompletny w sensie Turinga - a to znaczy że sprawdzi się (lepiej lub gorzej, ale zawsze) w 99% zastosowań. I o hosting bardzo łatwo. Jeśli wyrobisz się w nim w terminie, i nie doprowadza cię do szewskiej pasji, nie ma sensu zmieniać.

Offline Xender

  • Użytkownik

# Luty 11, 2014, 18:26:40
Jedyna kwestia którą mógł bym podać jeszcze dyskusji to wady i zalety PHP w tym wypadku. Zawsze można wszystko szybko przepisać, ale czy faktycznie jest sens?
Nie wspominałeś, że masz już jakiś codebase w PHP - w takim wypadku chyba nie warto pochopnie zmieniać języka.