Sicherer login

P

PsychoCat

Neues Mitglied
0
Hallo zusammen,

ich habe gerade angefangen mit der Android-Programmierung und es nach mühsamen Stunden hinbekommen eine Login-App zu schreiben. Dabei stehen die Daten in einer online mysql Datenbank. Meine App bekommt es nun hin zu schauen ob der eingegebene Username in der Datenbank vorhanden ist und ob das Passwort korrekt ist.

Nun wäre der nächste Schritt lokal zu speichern, dass ich eingeloggt bin und daher die Berechtigung habe auf weitere Daten aus der Datenbank zuzugreifen. Das würde ich in einer SQLite Datenbank machen, aber dabei stellt sich mir die Frage nach der Sicherheit des ganzen:

Wenn ich in der lokalen Datenbank jetzt einfach ein Feld erstelle, sagen wir "login" und das mit dem Wert der UserID fülle, als die ich mich mit Name und Passwort eingeloggt habe, dann erscheint mir das recht unsicher oder nicht? Oder anders gefragt wie leicht ist es die lokale Datenbank zu manipulieren und da einfach dann jede beliebige ID einzutragen, für die die App mich dann hält? Oder sollte ich ganz anders vorgehen?
 
Die Verifizierung muss immer auf dem Server stattfinden.

Wie kommunzierst du denn mit deiner datenbank?
Wenn du über HTTP kommunzierst müsstest du ja immer mitsenden, dass du eingelogt bist, das kann dann aber auch jeder andere senden.

Wenn du HTTP(S) benutzt kannst du die "normalen" Dinge nutzen, die z.B. auch das Forum benutzt damit du eingeloggt bleibst.
 
Jo, damit erzeugst du ein offenes Scheunentor.
Mögliche Angriffsmethoden wären:
-Brute-Force
-Speicher auslesen / manipulieren (kennt man von Cracks auf dem Computer)
-wahrscheinlich noch viele andere...

Ich meine Reneph hat mal einen ziemlich genialen PW-Manager programmiert, vielleicht kann/will er dir da Genaueres sagen.
Nach meinem aktuellen Wissenstand würde ich dir zu einer Salt-Verschlüsselung raten. (kann mich aber auch irren)
Salt (Kryptologie)

@amfa: dass die Verifizierung immer über den Server laufen muss bezweifle ich. Meiner Meinung nach würde es dem Prinzip der asynchronen Verschlüsselung widersprechen. Oder habe ich einen Denkfehler?
Was ich damit meine:
Der Entwickler legt für eine Person zwei Keypairs an (öffentlich und privat). Der öffentliche könnte eine Art ID sein und den privaten bekommt der Nutzer nur gegen Bezahlung. Und um seine Legitimation zu "bestätigen" muss der Nutzer aber seine Kennung privat verschlüsseln.
Und einen Algorithmus der das Erstellen von Keypairs "autonom" (offline) vollzieht, sollte es geben.
In der Theorie sollte es eigentlich so funktionieren.. :D
 
Zuletzt bearbeitet:
Mit Root-Rechten kann man alle Daten der App manipulieren.

Normalerweise (wie z.B. dieses Forum hier) wird das mit Sessions gelöst.

Ganz grob gesagt funktioniert das so:
  1. User loggt sich ein
  2. Server erstellt eine Session (merkt sich sozusagen den Status des Users)
  3. User erhält eine Identifikationsnummer der Session (genannt Session-ID)
  4. Jedes mal, wenn der User eine Anfrage an den Server schickt, sendet er die Identifikationsnummer mit
  5. Der Server schaut dann, ob die dazugehörige Session gültig ist / existiert

Damit gibst du dem User gar nicht die Möglichkeit, irgendwas manipulieren zu können. Er muss sich nur die Session-ID merken, aber die Daten der Session kann er nicht verändern, weil sie auf dem Server liegen.

Das setzt natürlich voraus, dass die Kommunikation von Client zu Server sicher ist (z.B. mit korrekt implementierten HTTPS). Sonst kann jeder die Session-ID kopieren und so die Session anderer User übernehmen -> Session Hijacking

@ui_3k1:

Symmetrische Verschlüsselung auf dem Smartphone des Users bringt in diesem Fall nicht viel, weil du fürs Ver-/Entschlüsseln jedes mal den Key brauchst. Dieser muss entweder jedes mal vom User eingegeben werden oder muss irgendwo gespeichert/generiert werden (was nicht viel Sinn macht, weil man den dann auslesen/die App dekompilieren kann). Daher kann der User die Daten entschlüsseln und manipulieren, weil er den Key selber hat oder vom Gerät holen kann.

Asymmetrische Verschlüsselung auf dem Smartphone bringt hier (so wie ich das sehe) auch nicht viel. Die App kann die Daten zwar so verschlüsseln (mit dem Public Key des Servers), dass nur der Server sie entschlüsseln kann (mit seinem Private Key). Das hindert aber niemanden daran, einfach andere Daten mit dem Public Key des Servers zu verschlüsseln und in der DB zu speichern. So kann man einfach den Login-Status in der lokalen Datenbank überschreiben, ohne die Daten entschlüsseln zu müssen. (Dazu muss man natürlich wissen, wie der Login-Status abgespeichert wird, aber dafür kann man ja die App dekompilieren)
 
Ahoi,
für dein Vorhaben empfehle ich dir folgende Vorgehesweise:
- Den Login unbedingt über SSL durchführen
- Wenn der Login Serverseitig erfolgreich ist, dann generiere ein Token (z.B. eine Guid/Uniqueidentifier) und gebe diesen an den User zurück. Diesen Token kannst du auf dem Handy speichern und bei jeder Anfrage mitsenden. Serverseitig musst du dann prüfen ob der Token zum Nutzer passt und ob er noch gültig ist.
Ein gutes Szenario ist z.B. den Token alle zwei Wochen ablaufen zu lassen. Ein Kennwort oder einen Hash würde ich nicht speichern. :)
 
ui_3k1 schrieb:
@amfa: dass die Verifizierung immer über den Server laufen muss bezweifle ich. (...)

Ich meine damit auch eher, dass der Client niemals ein flag "login" oder so mitsenden soll, sondern der Server muss entscheiden ob der aktuelle User eingeloggt ist oder nicht.

Ansonsten ist es zu einfach dieses flag zu fälschen.
Wenn also der Client entscheidet ob er eingeloggt ist, lässt sich das sehr sehr einfach umgehen.
 
amfa schrieb:
Wenn also der Client entscheidet ob er eingeloggt ist, lässt sich das sehr sehr einfach umgehen.

Jo, das stimmt. Nicht mal die ganz großen in der Branche bekommen es zuverlässig hin ihre Produkte gegen Piraterie zu schützen.
 
Vielen Dank erstmal für die ganzen Antworten!
Scheint ja keine so dumme Frage gewesen zu sein.. in so einem online tutorial war es nämlich einfach so, dass die app speichert, dass ich jetzt als UserID 1 eingeloggt bin und damit habe ich die entsprechenden Zugriffsrechte.

Ich nutze bisher nur ein "httpclient" und sende daten per "httppost". Kann ich damit auch über https bzw ssl senden?

Salt Verschlüsselung serverseitig habe ich (für die User-Passwörter), aber ich sehe das wie ihr, eine Verschlüsselung auf dem smartphone hilft nicht.

Also werde ich mich erstmal mit Sessions beschäftigen. Danke für die Erklärungen dazu, ich denke ich habe das Prinzip begriffen. Eigentlich müsste ich nur wissen wie man diese Session-ID erstellt. Das sollte dann ja mit php gehen (da die auf dem server erstellt wird)?

Ach und noch etwas: wieso sollte die ID (der Token) ablaufen?
 

Ähnliche Themen

F
Antworten
0
Aufrufe
837
FlorianAlfredo
F
J
Antworten
0
Aufrufe
557
JoEntwickler
J
M
Antworten
3
Aufrufe
169
moin
M
Zurück
Oben Unten