Sicherheit in eigener Anwendung...

Rund um die LCL und andere Komponenten
pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Edit: hab das bei Dashlane doch falsch verstanden, man registriert sich mit einem Device key, welchen man verschlüsselt auf dem Gerät haben muss mit dem man sich anmeldet und Geräte kann man mit einem Email oder SMS one time passwort registrieren. Das kann man natürlich bei einer Browseranwendung schlecht machen.

OK... Das wäre in meinem Konzept gar nicht mal so schlecht:
Ich möchte ja ein Rest-Client und Rest-Server haben. Wobei der Rest-Client irgendwas sein kann, ein Webserver eine Grafische Lazarus-Anwendung egal was.

Aber um das neuverschlüsseln beim Passwort wechsel wirst du wohl oder übel nicht herum kommen können.

Das wäre der Harken dabei: aber mal im ernst:
A) Ab wann wäre das wirklich ein Problem? Ab wie viele Einträge in der DB?
B) Wie oft würde man dieses Password ändern?

Das Passwort möchte man doch eher ändern als das login passwort. Das ist immerhin ohne das entschlüsselpasswort nutzlos

Stimmt auch wieder. Jedoch hat das den Vorteil, dass man nicht alles Verschlüsseln muss.
Es würde also mehrer Ebenen geben. Eine ebene, mit Einträgen die nicht extra geschützt sein müssen, eine ebene mit Daten die extra Verschlüsselt sein sollten.
Es könnte auch noch eine Ebene geben, die auch Personen sehen, die nicht angemeldet sind. Das ist hier mein Ziel.

Der Benutzer soll entscheiden, wenn er alles verschlüsseln möchte bitte. Ist aber kein muss.

Ich denke die Idee mit dem Rest-Server hat doch immer mehr Vorteile...
Das mit dem Sicherheits-Token in deinem Beispiel habe ich auch schon gesehen. Das muss ich mir noch genauer anschauen, weil das wäre der nächste Punkt.
D.H. der Client würde diesen Token immer mit Senden. Wenn es den Token nicht gibt, ist man auch nicht angemeldet.

Du machst das ja mit der IP. Nun ist die Frage in wie weit man das per JavaScript z.b. im WebBrowser angreifen könnte.
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Das wäre der Harken dabei: aber mal im ernst:
A) Ab wann wäre das wirklich ein Problem? Ab wie viele Einträge in der DB?
B) Wie oft würde man dieses Password ändern?

Stimmt auch wieder. Jedoch hat das den Vorteil, dass man nicht alles Verschlüsseln muss.
Es würde also mehrer Ebenen geben. Eine ebene, mit Einträgen die nicht extra geschützt sein müssen, eine ebene mit Daten die extra Verschlüsselt sein sollten.
Es könnte auch noch eine Ebene geben, die auch Personen sehen, die nicht angemeldet sind. Das ist hier mein Ziel.

Der Benutzer soll entscheiden, wenn er alles verschlüsseln möchte bitte. Ist aber kein muss.

Du solltest das neu verschlüsseln eh auf dem Clienten machen (sonst wäre es ja nicht end zu end verschlüsselt), das heißt der Nutzer muss die Leistung zur Verfügung stellen. Ich denke so häufig ändert man das passwort nicht das man dafür dann nicht mal eben 10 minuten haben sollte

pluto hat geschrieben:Das mit dem Sicherheits-Token in deinem Beispiel habe ich auch schon gesehen. Das muss ich mir noch genauer anschauen, weil das wäre der nächste Punkt.
D.H. der Client würde diesen Token immer mit Senden. Wenn es den Token nicht gibt, ist man auch nicht angemeldet.

Du machst das ja mit der IP. Nun ist die Frage in wie weit man das per JavaScript z.b. im WebBrowser angreifen könnte.


Ja ich häng das Token an die IP damit, selbst wenn man das Token bekommt, man sich nur vom tatsächlichen Gerät anmelden kann. Hat ein paar Nachteile, z.B. mobile Geräte Wechseln oft zwischen Mobilem Netz und Wlan, das sind immer IP wechsel (mein beispiel ist aus einem Desktop Only programm daher juckte mich das nicht) und das zweite Problem ist das leute aus dem selben NAT natürlich auch die selbe IP haben (man könnte dagegen noch den Port mit hashen). Würden ISP's IPv6 mit Mobile Header unterstützten wären die beiden Probleme auch schon nicht mehr, aber den standard gibts ja erst seit 20 Jahren, das ist noch viel zu neumodisch.
Der vorteil bei der IP ist, wenn man die IP addresse spooft (also einfach eine andere IP reinschreibt) versucht der Server mit der falschen IP zu sprechen, die SSL verbindung würde sich nicht mal aufbauen lassen, ist also nicht so einfach zu fälschen wie z.B. Mac Adresse.
Für eine webapp schreib das Token einfach in einen Cookie, statt wie bei meinem beispiel das Token in den HTTP Body zu schreiben

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Du solltest das neu verschlüsseln eh auf dem Clienten machen (sonst wäre es ja nicht end zu end verschlüsselt), das heißt der Nutzer muss die Leistung zur Verfügung stellen. Ich denke so häufig ändert man das passwort nicht das man dafür dann nicht mal eben 10 minuten haben sollte

Wenn ich sowas einbaue, wäre das wohl am Sinnvollsten...

Ja ich häng das Token an die IP damit, selbst wenn man das Token bekommt, man sich nur vom tatsächlichen Gerät anmelden kann. Hat ein paar Nachteile, z.B. mobile Geräte Wechseln oft zwischen Mobilem Netz und Wlan, das sind immer IP wechsel (mein beispiel ist aus einem Desktop Only programm daher juckte mich das nicht)

Dachte ich mir schon und vorallem, wenn man eine neue IP erhält. Das Passiert aber nicht mehr so häufig heut zu Tage...
Ich frage mich, ob man die IP nicht auch selbst "dran" hängen könnte, wenn die bekannt ist. Von einem HTTP Header kann man ja viel Manipulieren.

und das zweite Problem ist das leute aus dem selben NAT natürlich auch die selbe IP haben (man könnte dagegen noch den Port mit hashen). Würden ISP's IPv6 mit Mobile Header unterstützten wären die beiden Probleme auch schon nicht mehr, aber den standard gibts ja erst seit 20 Jahren, das ist noch viel zu neumodisch.

Ja eben... was sind schon 20 Jahre...

Der vorteil bei der IP ist, wenn man die IP addresse spooft (also einfach eine andere IP reinschreibt) versucht der Server mit der falschen IP zu sprechen, die SSL verbindung würde sich nicht mal aufbauen lassen, ist also nicht so einfach zu fälschen wie z.B. Mac Adresse.

Ah gut zu wissen...

Für eine webapp schreib das Token einfach in einen Cookie, statt wie bei meinem beispiel das Token in den HTTP Body zu schreiben

Ich bin am überlegen, ob ich nicht erst mal eine Grafische Lazarus Anwendung erstelle, weil ich jetzt ein paar Komponenten gesehen habe(im Online-Manager), die ich vorher noch nicht kannte und die der Grund waren, warum ich das als Webanwendung geplant hatte.
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Ich bin am überlegen, ob ich nicht erst mal eine Grafische Lazarus Anwendung erstelle, weil ich jetzt ein paar Komponenten gesehen habe(im Online-Manager), die ich vorher noch nicht kannte und die der Grund waren, warum ich das als Webanwendung geplant hatte.


Webapps haben den Vorteil das man sie überall problemlos verwenden kann, aber grundsätzlich finde ich native Anwendungen besser, aus zwei Gründen. Zum einen Löscht man öfter mal Browserdaten (zumindest ich), das würde für deine Anwendung dann bedeuten das wenn du einen Device Key wie Dashlane verwendest, der weg wäre, zum anderen sind Webanwendungen inherent unsicher. Selbst wenn du die ganze Entschlüsselung auf dem Zielrechner hast, durch XSS (cross site scripting) oder diverse andere angriffe könnten angreifer einfach zusätzlichen Javascript Code injezieren der auf dem Clienten wartet bis die Entschlüsselung fertig ist und die Daten dann entspannt hochlädt, oder im worst case, jemand übernimmt den Server, kann mit den verschlüsselten daten zwar nichts anfangen, sendet dafür dann aber einfach böses Javascript. Im gegensatz dazu ist es viel schwerer Code in eine Native Anwendung zu Injezieren.

Eventuell könntest du dann auch überlegen den Login statt über ein Device Token über einen Privatekey-Publik Key verfahren (PGP, SSH) zu machen, wäre noch ein stückchen sicherer als Device keys (und als key könnte man z.B. den SSH oder PGP key verwenden die man eh schon hat).

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Webapps haben den Vorteil das man sie überall problemlos verwenden kann, aber grundsätzlich finde ich native Anwendungen besser, aus zwei Gründen. Zum einen Löscht man öfter mal Browserdaten (zumindest ich), das würde für deine Anwendung dann bedeuten das wenn du einen Device Key wie Dashlane verwendest, der weg wäre, zum anderen sind Webanwendungen inherent unsicher

Darum auch die Idee mit der Rest-Api und dem Lokalen Webserver....

Eventuell könntest du dann auch überlegen den Login statt über ein Device Token über einen Privatekey-Publik Key verfahren (PGP, SSH) zu machen, wäre noch ein stückchen sicherer als Device keys (und als key könnte man z.B. den SSH oder PGP key verwenden die man eh schon hat).

Das habe ich mir auch schon überlegt, nur: Gibt es für Lazarus bereits Units dafür? Ich würde es nicht unbedingt gerne über Externe Anwendungen machen....
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Das habe ich mir auch schon überlegt, nur: Gibt es für Lazarus bereits Units dafür? Ich würde es nicht unbedingt gerne über Externe Anwendungen machen....


Natürlich kann OpenSSL das, da solltest du am besten für nach C code suchen und den versuchen zu übersetzen. Ansonsten würde ich empfehlen eventuell aber die möglichkeit zum verwenden von externen Anwendungen zu bieten. z.B. ich habe einen YubiKey, eine kleine SmartCard mit vielen Tollen Funktionen, eine davon ist PGP Signieren, Verschlüsseln und Authentifizierung. Dabei bleiben alle Keys auf dem YubiKey, welcher als eigenständiger Computer die aufgaben übernimmt und nur das verschlüsselte paket am ende zurückgibt. Das Teil mit OpenPGP zu registrieren ist super einfach und ich denke das es dafür wohl kaum eine Bibliothek gibt.

Grad zu dem Thema Smartcards ist auch U2F interresant, ich kann sowas nur wärmstens empfehlen, so teuer sind Smartcards nicht, und erhöhen die Sicherheit immens. Wenn du auf sicherheit wert legst solltest du mal überlegen sowas auch zu implementieren.

Ich würde wahrscheinlich sogar komplett auf PGP gehen, nicht nur die Authentifizerung sondern dann auch das ver und entschlüsseln über PGP machen und die Exsistenz von PGP entweder vorraussetzen, oder sicher stellen das PGP exsistiert. Linux geht das ja ganz einfach über package dependencies, bei Windows würde ich einfach WinPGP mitliefern, so wie der Lazarus installer im lazarus directory einfach FPC und die CoureUtils (z.B. make) mitliefert die benötigt werden.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Pass ist das was der Client als passwort sendet also steht da eigentlich SHA256(Salt + SHA256(Username + Password)). Wobei der Server ja nicht weiß was Password ist, da er SHA256(Username + Password) ja vom user gesendet bekommt. Der server wird also genauso implementiert wie wenn der Client nicht salten würde und behandelt das was der client ihm gibt als login passwort.

Ich habe mir diese Aussage noch mal durchgelesen, dabei ist mir eine Sache aufgefallen, die mir so nicht gefällt(Wenn ich sie richtig verstanden habe):
Wenn ich das Login Password nun ändere, müsste ich es neu in der DB ablegen. Da es ja sonst nicht mehr Stimmen wird.

Du solltest das neu verschlüsseln eh auf dem Clienten machen (sonst wäre es ja nicht end zu end verschlüsselt), das heißt der Nutzer muss die Leistung zur Verfügung stellen. Ich denke so häufig ändert man das passwort nicht das man dafür dann nicht mal eben 10 minuten haben sollte

D.H. Alle Einträge die ein User gemacht haben, sollten einmal zum User zurück auf dem Client Rechner dort einmal alle entschlüsselt werden und dann erneut verschlüsselt werden?
Gut, für ein paar Personen ist das kein Problem, aber bei einer größeren Nutzer zahl schon.
Der Server soll die Einträge ja auf jedenfall nicht entschlüsseln...
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Ich habe mir diese Aussage noch mal durchgelesen, dabei ist mir eine Sache aufgefallen, die mir so nicht gefällt(Wenn ich sie richtig verstanden habe):
Wenn ich das Login Password nun ändere, müsste ich es neu in der DB ablegen. Da es ja sonst nicht mehr Stimmen wird.

Wenn das Login Passwort geändert wird, sendet der Client SHA256(User + NewPW), der server müsste einen neuen Salt erstellen, und dann Salt + ClientDaten hashen und die Datenbank mit dem neuen hash und dem neuen Salt updaten

D.H. Alle Einträge die ein User gemacht haben, sollten einmal zum User zurück auf dem Client Rechner dort einmal alle entschlüsselt werden und dann erneut verschlüsselt werden?
Gut, für ein paar Personen ist das kein Problem, aber bei einer größeren Nutzer zahl schon.
Der Server soll die Einträge ja auf jedenfall nicht entschlüsseln...

Du kannst das ja auch im hintergrund machen, wenn du das passwort änderst wird eine liste aller verschlüsselten dateien erstellt, und zusammen mit dem alten Passwort verschlüsselt (mit dem neuen passwort als schlüssel). Der Client fängt dann bei jedem login an diese Liste runterzuladen, die dateien von der liste runterzuladen, zu ent und dann neu verschlüsseln und diese zusammen mit der neuen liste (ohne diese datei) hochladen. Somit muss man nicht nach einem passwort wechsel 10-20 minuten am stück warten, sondern kann jederzeit stoppen, und wenn man auf die alt verschlüsselten Dateien zugreifen will bevor sie neu verschlüsselt wurden kannst du einfach das alte PW aus der liste verwenden

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Du kannst das ja auch im hintergrund machen, wenn du das passwort änderst wird eine liste aller verschlüsselten dateien erstellt, und zusammen mit dem alten Passwort verschlüsselt (mit dem neuen passwort als schlüssel). Der Client fängt dann bei jedem login an diese Liste runterzuladen, die dateien von der liste runterzuladen, zu ent und dann neu verschlüsseln und diese zusammen mit der neuen liste (ohne diese datei) hochladen. Somit muss man nicht nach einem passwort wechsel 10-20 minuten am stück warten, sondern kann jederzeit stoppen, und wenn man auf die alt verschlüsselten Dateien zugreifen will bevor sie neu verschlüsselt wurden kannst du einfach das alte PW aus der liste verwenden

das wäre keine schlechte Idee. Weil ich müsste aufjedenfall alle Verschlüsselten Einträge aus der DB exportieren. Ich denke der User sollte die Methode auswählen.
Je nach Anzahl der Verschlüsselten Einträge kann das sinn machen.... Ich frage mich nur, ab wann wird das spürbar?
Angenommen ich hätte 100 User, diese 100 User haben je 30 Verschlüsselte Einträge. Nun wollen drei oder vier User zur gleichen Zeit das Password ändern....

Mir ist außerdem aufgefallen: es muss bereits ein User in der Datenbank geben, damit der Client neue User hinzufügen kann bzw. damit das ganze Konzept aufgeht.
Dieser eine User muss natürlich Admin-Rechte haben...

Spannende Fragen...

Vielleicht könnten wir dazu mal ein Komplexeres Beispiel erstellen...Mit einer einfachen Rest API...Wenn mein Projekt so weit ist werde ich es hochladen.

ps: Nun habe ich auch eine Domaine. Ich muss zwar noch etwas warten, aber nun kann ich ein Server-Zertifikat beantragen für TTL(Hieß das so?) Somit bräuchte ich mir keine weiteren Gedanken für die Transport Verschlüsslung machen oder ich biete es als extra Option an, wenn man kein Server-Zertifikat hat.
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Je nach Anzahl der Verschlüsselten Einträge kann das sinn machen.... Ich frage mich nur, ab wann wird das spürbar?
Angenommen ich hätte 100 User, diese 100 User haben je 30 Verschlüsselte Einträge. Nun wollen drei oder vier User zur gleichen Zeit das Password ändern....

Keine ahnung, sowas muss man einfach mal austesten

pluto hat geschrieben:Mir ist außerdem aufgefallen: es muss bereits ein User in der Datenbank geben, damit der Client neue User hinzufügen kann bzw. damit das ganze Konzept aufgeht.
Dieser eine User muss natürlich Admin-Rechte haben...

Was genau meinst du damit?

pluto hat geschrieben:ps: Nun habe ich auch eine Domaine. Ich muss zwar noch etwas warten, aber nun kann ich ein Server-Zertifikat beantragen für TTL(Hieß das so?) Somit bräuchte ich mir keine weiteren Gedanken für die Transport Verschlüsslung machen oder ich biete es als extra Option an, wenn man kein Server-Zertifikat hat.

TLS/SSL meinst du, schau dir mal Let's Encrypt an, eine offene SSL Authorität die kostenlos zertifikate austellt.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Was genau meinst du damit?

Naja, wenn es noch keine Nutzer in der Datenbank Tabelle Eingetragen sind, kann sich der Client auch nicht anmelden oder?
Außerdem muss der Admin auch gewisse Einstellungen im Vorfeld vornehmen: Dürfen sich Benutzer einfach so Registrieren?
oder müssen sie Frei geschaltet werden von einem Admin oder einem Mod? Je nach dem, wie man das System einstellt.
Sind z.b. Dateianhänge an eine Notiz erlaubt? Wenn ja, gibt es ein Limit? Gibt es ein Klar Namen Zwang?(Wird ja gerade in der Politik diskutiert bzw. war mal im Gespräch)

TLS/SSL meinst du, schau dir mal Let's Encrypt an, eine offene SSL Authorität die kostenlos zertifikate austellt.

Ja, danke für den Tipp, werde ich machen. Mein Bruder hat gestern noch "Certbot" vorgeschlagen... Ich werde mir mal beide ansehen.

Ein Zertifikate wäre auf jedenfall für einige Anwendungen Praktisch z.b. auch für MQTT oder aber auch für das Ethernet-Pad System...
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

pluto hat geschrieben:Naja, wenn es noch keine Nutzer in der Datenbank Tabelle Eingetragen sind, kann sich der Client auch nicht anmelden oder?
Außerdem muss der Admin auch gewisse Einstellungen im Vorfeld vornehmen: Dürfen sich Benutzer einfach so Registrieren?
oder müssen sie Frei geschaltet werden von einem Admin oder einem Mod? Je nach dem, wie man das System einstellt.
Sind z.b. Dateianhänge an eine Notiz erlaubt? Wenn ja, gibt es ein Limit? Gibt es ein Klar Namen Zwang?(Wird ja gerade in der Politik diskutiert bzw. war mal im Gespräch)

Ja klar, du wirst irgend eine form von Berechtigungsystem benötigen (z.B. Bitmask als berechtigungsflags)

pluto hat geschrieben:Ja, danke für den Tipp, werde ich machen. Mein Bruder hat gestern noch "Certbot" vorgeschlagen... Ich werde mir mal beide ansehen.

Ein Zertifikate wäre auf jedenfall für einige Anwendungen Praktisch z.b. auch für MQTT oder aber auch für das Ethernet-Pad System...


Der certbot ist ein programm um Let's Encrypt zertifikate zu installalieren

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Sicherheit in eigener Anwendung...

Beitrag von Timm Thaler »

Wie stellt man eigentlich sicher, dass Inhalte die die Datenbank in den Speicher lädt um damit arbeiten zu können im Speicher nicht unverschlüsselt rumliegen?

Das scheint auch das Angriffsschema bei Keypass zu sein: Die Passwörter werden bei offenem Programm aus dem Speicher ausgelesen.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Sicherheit in eigener Anwendung...

Beitrag von pluto »

Wie stellt man eigentlich sicher, dass Inhalte die die Datenbank in den Speicher lädt um damit arbeiten zu können im Speicher nicht unverschlüsselt rumliegen?

Aber du möchtest damit ja arbeiten, also müssen sie doch irgendwo unverschlüsselt rumliegen? Z.B. im WebBrowser, wenn die dort angezeigt werden.

Das scheint auch das Angriffsschema bei Keypass zu sein: Die Passwörter werden bei offenem Programm aus dem Speicher ausgelesen.

Ja, unter Linux muss man das Password ja zwischendurch recht häufig eingeben.... Da freuen sich die Keylogger.
MFG
Michael Springwald

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Sicherheit in eigener Anwendung...

Beitrag von Warf »

Timm Thaler hat geschrieben:Wie stellt man eigentlich sicher, dass Inhalte die die Datenbank in den Speicher lädt um damit arbeiten zu können im Speicher nicht unverschlüsselt rumliegen?


Gar nicht, man muss immer davon ausgehen das der Server infiziert werden kann. Daher werden Daten auf dem Server nie entschlüsselt. Passwörter legt man somit zum Beispiel nur als gesaltete Hashes ab, die man nicht mehr auslesen (aber da man weiß gleiches Passwort = Gleicher Hash kann man es immernoch zum Login verwenden) kann und für die Daten die entschlüsselt werden verwendet man End zu End verschlüsselung. Also das entschlüsseln muss auf dem Clienten stattfinden. Somit kann der Server infiziert sein wie er will, an deine Daten kommt er nicht ran

Timm Thaler hat geschrieben:Das scheint auch das Angriffsschema bei Keypass zu sein: Die Passwörter werden bei offenem Programm aus dem Speicher ausgelesen.


Ja wenn das end gerät infiziert ist hast du verloren. Da braucht man meist nicht mal den Speicher auszulesen, es reicht schon einen ganz normalen keylogger zu installieren. Am schlimmsten ist natürlich hardware zugriff, wenn ich hardware zugang zu deinem PC hab dann kann ich machen was ich will. Ich könnte z.B. deinen Bootloader infizieren, sodass der erste code der vom System ausgeführt wird bereits schadcode ist. Man kann auch hardware keylogger verwenden (kleine usb geräte die man zwischen PC und tastatur hängt), das ist Software mäßig gar nicht zu erkennen (und zumindest ich benutz meinen Computer schonmal über monate hinweg ohne einmal nachzuschauen ob meine tastatur noch richtig eingesteckt ist).

Als Dienstleister kann man nur sichergehen das alles bis zum End nutzer möglichst sicher ist, ab da muss der Nutzer selbst sich um die Sicherheit kümmern

Antworten