Ich habe mich inzwischen auf die ingelassen (oh ja, es passieren auch noch Wunder
). Deswegen versuche ich jetzt ja schon die Daten verschlüsselt zu senden bzw gar nicht erst mitzugeben.
alleine die überlegung die daten im client mit auszuliefern ist sicherheitstechnisch grundlegend falsch
rein sicherheitstechnisch betracht müsste es nur heißt : gar nich erst mitgeben ...
seh ich inzwiscen auch ein, das hat mir aber geholfen, dass man aus der *.class Datei nicht mehr lesen kann.
gut ... aber da es die VM ja trotzdem ausführen muss muss zumindest während der runtime java-fähiger byte-code im RAM liegen ... und den kann man mit einfachen tools dierekt auslesen ...
war dieses "bahnhof" gegen "man-in-the-middle" gerichtet ? da kannst du dir bei wikipedia was zu durchlesen ...
heißt im endeffekt nicht mehr und nicht weniger als das du dem client vorspielst der server zu sein und dem server vorspielst der client zu sein ... da man nun beide verbindungen kontrolliert kann man dazwischen *also im "hack-programm"* die daten plain mitlesen und sogar manipulieren ...
Es ist sowieso UNMÖGLICH etwas 100%ig sicher zu machen. Nehmen wir das Pentagon: Mit einem schnellen Rechner und VIEL Glück kann man sich auch dort in weniger als 30Jahren einhacken
.
Um etwas zu schützen geh es nur darum, es so aufwändig wie möglich zu machen, sodass es sich nicht lohnt.
Wie lange dauert es denn dieses FTPS zu knacken? Wie viel Arbeit ist denn nötig, um ein paar Datein auf einen "nur" 1GB großen Server zu laden? Ist das Zeit-Leistungs-Verhältnis immernoch gut genug dafür?
stimme ich dir soweit zu ...
wie lange es dauern würde FTPS zu knacken ? mit eingem copy&paste keine 5 minuten da du dem client nur eine "gültige" server-implementierung vorspielen musst ...
um dabei keien fehler zu bekommen importiert man das "hack-zertifikat" einfach in seiner JRE und hebelt damit alle sicherheitsvorkehrungen in richtung SSL vollständig aus da das zertifikat als "vertrauenswürdig" installiert wurde ... und du kannst davon ausgehen das das ein hacker machen wird ...
damit hast du also die daten plain ... um jetzt noch ne verbindung mit dem eigentlichen ziel aufzubauen verbindest du dich wie deine eigentliche app ...
du siehst also : FTPS *und auch SFTP* ist durch man-in-the-middle ... also das vorspielen des gegenparts an die beiden seiten kein problem *bei SFTP muss man zusätzlich das SSH spoofen ... ist aber ungleich schwerer*
Und ich werde "über Leichen gehen" *im übertragenen Sinne gemeint*, um es mit JAVA halbwegs unrentabel zu machen :lol: .
es gibt dinge ... die sollte man besser nicht mit reinem java umsetzen ... *mal von denen abgesehen die mit reinem java unmöglich sind* ...
:bahnhof: Woher weißt du sowas :shock: =?
in dem ich im englischem wikipedia nachgelesen habe
FTPS - Wikipedia, the free encyclopedia
SSH File Transfer Protocol - Wikipedia, the free encyclopedia
nach dem das deutsche nun wirklich so gut wie nichts wissenswerte enthält
FTP über SSL ? Wikipedia
SSH File Transfer Protocol ? Wikipedia
es kommt vor allem auf die quelle an aus der man sich informationen beschafft
Der Witz ist, dass mir der Server bei FTPS auch verschlüsselt antwortet und bei System.out.println(ftp.login(...,...)) ein true kommt. Ich kann mich also über FTPS einloggen und auch bei ftp.changeWorkingDirectory(...) liefert er true. Warum aber ffs ist dann der IS null!?!
dann sei doch froh das dein hoster FTPS unterstützt ... nur wirklich sicherer macht es das ganze immer noch nicht ...
warum da jetzt irgendwas irgendwie irgendwann NULL ist ... keine ahnung ... würde mich selbst damit aber auch nicht weiter befassen
Und wie soll das passieren? Das wird doch nur max. 1s im RAM hinterlegt, bevor der GC es löscht...
ouh da liegst du weit daneben ...
um das zu erreichen müsstest du schon die login-daten jedes mal von einer externen quelle laden ... und dann nach zusammenbau und übertragung der login-daten auch wirklich ALLE objekte vernichten ... dazu reicht es nicht aus nur irgendwas NULL zu setzen und darauf zu hoffen das der GC es IRGENDWANN mal regräumt ...
gerade bei STRING ist das ohne tiefe system-eingriffe wegen des String-pools eh nicht möglich ... und was den stack eines network-outputstreams angeht bin ich mir sicher das man auch da irgendwo noch buffer-daten findet ...
was ich jedoch meine ist das du die daten in deiner client-app hinterlegen willst ... diese also IMMER in der entsprechenden datei vorliegen ... und egal wie sehr du das ganze auch noch sichern magst ... so lange deine app in der runtime ist liegt die gesamte app und damit auch die zugangsdaten im RAM ...
Ich würde schon gerne in JAVA bleiben und wie du gesehen hast, denke ich inzwischen auch über den Missbbrauch nach. Hätte ich dich vollständig ignoriert, hätte ich diese Frage niemals gestellt, sondern einfach weiterhin mit FTPClient und FTP-URL geareitet. Aber ich versuche jetzt schon, meinen Server unlohnendswert (falls es dieses Wort gibt
)wie möglich zu machen.
es ist ja schon mal ein anfang das du mitlerweile wenigstens anfängst dir darüber gedanken zu machen ...
das problem ist allerdings das du immer noch an einer viel zu unsicheren methode festhältst welche schon zu seiten ihrer erfindung *und damit spiele ich jetzt mal auf die damals vergleichsweise schwache rechenleistung der rechner an* knackbar war ... und zwar genau so einfach wie heute ... da sich nämlich die verwendeten techniken nicht geändert haben *klar geht es heute in zeiten von 12-core cpus mit 12x 4,5GHz deutlich schneller als noch zu zeiten des i386er ... aber nur in hinblick auf das knacken hoch-sicherer crypto-verfahren ... ein man-in-the-middle war damals genau so einfach ...*
was ich also ausdrücken wollte war lediglich das die methode mit der du dein vorhaben umsetzen willst einfach zu unsicher ist ... und habe dir daher geraten es mit methoden zu versuchen welche deutlich sicherer sind *z.b. einsatz von server-sprachen wie PHP oder JSP ... das einzige was hier passieren kann *wenn richtig umgesetzt* ist das jemand eine falschen wert senden könnte ... dies sollte aber vom server erkannt und entsprechend reagiert werden ...*
Deswegen hoffe ich, dass Du mich weiterhin unterstützt und bitte nicht sofort negativ herangehst.
mfg
BH16
PS: Danke übrigens für den massigen Input, ich denke mit deinem Gerede über die Sicherheit hast du mein Denken über die Verbindung neu strukturiert.
negativ nur desswegen weil du wirklich schon eine ganze weile mit dieser idee hier durchs forum geisterst und dir wie erwähnt mehrfach von verschiedenen usern gesagt wurde das alle deine bisherigen *und auch deine jetzigen* sicherungsversuche auf grund der "einfachheit" der verwendeten protokolle und deren verknüpfung alle samt schwachstellen aufweisen welche *auch wenns jetzt krass kommt* von jedem 12-jährigem "script-kiddie" wie es immer so schön heißt umgangen werden kann ...
alles was man dazu braucht findet man bei google ...