PureBoard

das größte Problem dürfte da wohl auch eher sein, das ein Netzwerksniffer einfach das Passwort ausspucken wird, weil PB keine verschlüsselte Verbindung zum FTP-Server aufbauen kann. Selbst bei einer verschlüsselten Verbindung müsstest du erstmal sicherstellen, ob der Server wirklich dein Server ist.
Solche Abfragen dürfte jedes "ScriptKiddy" drauf haben.

Die Grundidee mittels FTP zugriffe zu locken ist einfach unbrauchbar.

GPI hat geschrieben:das größte Problem dürfte da wohl auch eher sein, das ein Netzwerksniffer einfach das Passwort ausspucken wird, weil PB keine verschlüsselte Verbindung zum FTP-Server aufbauen kann. Selbst bei einer verschlüsselten Verbindung müsstest du erstmal sicherstellen, ob der Server wirklich dein Server ist.
Solche Abfragen dürfte jedes "ScriptKiddy" drauf haben.

Die Grundidee mittels FTP zugriffe zu locken ist einfach unbrauchbar.

Naja libcurl kann ja FTPS und die lib wird mit PB ausgeliefert. Man würde dafür nur das Include benötigen. Die Authetifizierung des Servers würde ja theoretisch über da Zertifikat erfolgen. Zur Not hinterlässt man noch ein oder zwei Brotkrummen.

TroaX hat geschrieben:Naja libcurl kann ja FTPS und die lib wird mit PB ausgeliefert. Man würde dafür nur das Include benötigen. Die Authetifizierung des Servers würde ja theoretisch über da Zertifikat erfolgen. Zur Not hinterlässt man noch ein oder zwei Brotkrummen.

Nunja, Das Zertifikat - welches? Das in System installiert ist? Oder das in der Exe, das man austauschen kann?

Wobei das ist eine Standard-Lib. Gibts da nicht Lösungen die Lib-Teile in einer Exe zu suchen und durch manipulierte Versionen auszutauschen? Ähnliches gibt es ja bei Spielen (DirectX-Injektoren) um zusätzliche Effekte etc. einzuschalten.

Die beste Lösung ist immer noch ein Script auf den Server laufen zu lassen, das Informationen entgegennimmt, diese überprüft (ganz wichtig) und dann weiterverarbeitet. Alles andere ist einfach unsicher.

Ich wäre sogar dafür, dass jeder Nutzer der Software einen Online-Account benötigt, wenn er Daten mit einem Server austauschen will. Vor allem, wenn er Daten verändern darf, ist das unabdingbar. Bei Missbrauch wird so ein Account dann eben gesperrt. Zusätzlich kann man dann noch eine Transaktionsliste auf dem Server führen, die bereits stattgefundene Aktionen rückgängig machen kann.

NicTheQuick hat geschrieben:Ich wäre sogar dafür, dass jeder Nutzer der Software einen Online-Account benötigt, wenn er Daten mit einem Server austauschen will. Vor allem, wenn er Daten verändern darf, ist das unabdingbar. Bei Missbrauch wird so ein Account dann eben gesperrt. Zusätzlich kann man dann noch eine Transaktionsliste auf dem Server führen, die bereits stattgefundene Aktionen rückgängig machen kann.

@nic
er will nur wissen, wie oft sein Programm wo gestartet wird

Das kann man dann ja mit einem PHP-Skript machen. Zusammen mit einem Zufälligen Key pro Kunde bzw. Installation kann man dann ziemlich genau die eindeutige Anzahl an Installationen herausbekommen.

So mache ich das jetzt auch.

von GPI (Seite 1) >> "Ansonsten seh ich eher das Problem, das auf die Datei zeitgleich zugegriffen wird."

Jo, da war schon die Idee, dass die Dateinamen zufällig erstellt werden. Ohne dem hät's wirklich gehackt. ^^

Ich mache ein Skript. Sicher/er ist sicher/er.

Vielleicht habe ich das falsch verstanden, doch meine Idee wäre noch das Passwort eingeben zu lassen.
Klar ist es dadurch nach wie vor in Klartext, dafür aber nicht in der Executable selbst und kann somit nicht "gefunden" werden.

Hindert trotzdem nicht das ganze bei Klartext mit zum Beispiel Wireshark auszulesen.

Bei einem PHP Script sollte man das ebenfalls mit Wireshark auslesen können, da die eingegebenen Passwörter ja die Tastatur über den PC, deine Leitung ins Internet verlassen.

Autonomus hat geschrieben:Hindert trotzdem nicht das ganze bei Klartext mit zum Beispiel Wireshark auszulesen.

Bei einem PHP Script sollte man das ebenfalls mit Wireshark auslesen können, da die eingegebenen Passwörter ja die Tastatur über den PC, deine Leitung ins Internet verlassen.

Wenn auf einer Webseite HTTPS benutzt wird, kann man keine Daten aus der Kommunikation zwischen Client und Server auslesen. Und selbst ohne HTTPS kann man es einem Angreifer mit Hashing-Verfahren, die natürlich beide Seiten unterstützen sollten, mehr als schwer machen.