Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
ok, mal andersrum:
Warum geht Homebankibg ohne VPN?
Sind die Sicherhwitsanforderungen geringer?
Tja, das ist die Frage! Wie sind Deine Sicherheitsanforderungen an Homebanking?
Also meine sind da doch etwas höher als beim Zugriff auf den Lichtschalter, deswegen findet das ausschliesslich per HBCI mit Smartcard und Klasse3 Leser statt.
Den PIN/TAN bullsh** kann man ja auch machen, als Kunde "mutig", als Bank IMHO grob fahrlässig
Ein anderes OS booten, um zu gucken, ob das Licht aus ist?
OpenVPN geht unter Windows, Mac (Tunnelblick), Linux, Andriod >=4 aus der Box, iOS nur mit Jailbreak, kann ich nix für, da die Alternative PPTP..
Der Punkt ist: man kann Anwendern/Laien nicht mit 5 Sätzen alles erklären, was da wichtig ist (die Authentisierung viel mehr als die verschlüsselung!) also gbt es eine fertige, unter gegebenen Umständen möglichst sichere Lösung: das VPN.
Es führen auch 100 andere Wege nach Rom, wenn man sich sicher ist, das man weiss was man da tut
Um zum Homebanking zurückzukommen, da haben die Banken in den letzten 10J 20x nachkorrigiert obwohl klar war das es bullsh** ist.
Ich empfehle daher lieber, es gleich richtig zu machen
Tja, das ist die Frage! Wie sind Deine Sicherheitsanforderungen an Homebanking?
https
Also meine sind da doch etwas höher als beim Zugriff auf den Lichtschalter, deswegen findet das ausschliesslich per HBCI mit Smartcard und Klasse3 Leser statt.
Den PIN/TAN bullsh** kann man ja auch machen, als Kunde "mutig", als Bank IMHO grob fahrlässig
Da haben wir den Salat: Wir haben unterschiedliche Sicherheitsanforderungen. Ich sage mir: Der Bank reicht https. Für Schäden, die entstehen haften die Banken ja i.d.R. Ganz ehrlich ist mir da -außer pishing- aber nix bekannt.
Und für meine Lichtschalter reicht mir dann HTTPs auch.
OpenVPN geht unter Windows, Mac (Tunnelblick), Linux, Andriod >=4 aus der Box, iOS nur mit Jailbreak, kann ich nix für, da die Alternative PPTP..
Ist mir bekannt. Oben war die Rede von "vom Stick booten". Daher.
Der Punkt ist: man kann Anwendern/Laien nicht mit 5 Sätzen alles erklären, was da wichtig ist (die Authentisierung viel mehr als die verschlüsselung!) also gbt es eine fertige, unter gegebenen Umständen möglichst sichere Lösung: das VPN.
Ist m.M. nicht anwenderfreundlich, da ein Programm auf dem Client benötigt wird. Gerade das wird bei der CV ja -zu Recht- als Vorteil propagiert.
Was spricht also dagegen (ggf. zusätzlich) https vorzukonfigurieren?
Das reicht nicht, da Du dann noch Authentifizierung brauchst. Und da gehts dann halt weiter.
Login/Pw will man nicht immer eintippen. Ggf. kann man es "speichern". Also will man ein Clientzertifikat, damm man Login/Pw spart. Und das müsste man nun auch bei Tante Hilde importieren... Es muss korrekt erzeugt werden und und und.
Derzeit zwischen Kistenauspacken und Garten anlegen.
Baublog im Profil.
Tschuldigung: https mit User und Pass in der URL, als Lesezeichen, oder bei Tante Hilde eben eingetippt.
User und Pass kann ich mir merken, das Zertifikat nicht...
Aber nicht nur Du, auch Tante Hilde's Browser-History oder die vom Internetcafe-PC.
(Die Fragestellung ob die komplette URL verschlüsselt wird lautete "niemand in der Mitte". Am Anfangs- und Endpunkt sieht man die URL natürlich im Klartext, ja nach Browsereinstellungen mindestens in der Adresszeile und der History, ggf. auch noch im Cache (wenn nicht für https deaktiviert) und diversen "Sicherheitstools" di als transparenter Proxy / Webfilter arbeiten und dafür ggf. die URL sogar an einen Onlinedienst überträgt um die "Reputation" zu überprüfen...)
Was spricht also dagegen (ggf. zusätzlich) https vorzukonfigurieren?
Etwas ganz einfaches: es ist komplexer als der gemeine Anwender denkt.
In der Einrichtug (Namen müssen stimmen), in der richtigen Anwendung, im Support und letztlich Fehlerträchtig..
Wenn jemand Zertifikate bei Tante Hilde hinterlässt, verstehen die meisten intuitiv das das dazu führen kann das Tante Hilde eben...
Letztlich ist es aber ja technisch einfach möglich und hier sogar beschrieben, darf ja jeder machen.
Vorkonfiguriert und sicher beisst sich aber da bzw. sprengt ganz einfach den Rahmen bei einem Gerät für 357.- EUR deutlich.. Als individuelle Dienstleistung/Beratung kann man das einkaufen
Was spricht also dagegen (ggf. zusätzlich) https vorzukonfigurieren?
Interessante Diskussion. Gestattet mir, dass ich meine Meinung auch noch einbringe.
Um einen einzelnen Service übers Internet zugänglich zu machen, zumal für Endgeräte ausserhalb meiner Kontrolle, würde ich kein VPN nutzen. Warum sollte ich dafür mein ganzes Netz resp alle Ports öffnen? Bei einem eigenen Endgerät mit umfassender Nutzungsbreite hingegen ist ein VPN das richtige Zugriffsverfahren.
Den direkten Zugriff auf einen internen Webserver übers Internet würde ich keinesfalls zulassen. Vielmehr würd ich einen ReverseProxy mit SSL-Terminierung und Authentisierung davor schalten (z.B ein AP mit OpenWrt und Apache in meinem Fall). Daran können Angreifer dann rütteln ohne dass mein interner Webserver etwas davon merkt. Reicht dafür eine Username/Passwort-Authentisierung nicht aus, könnte man eventuell OneTimePassword mit skey einbinden.
Die Verwendung von Username/Passwort im HTTP(s)-URL ist weder empfehlenswert noch RFC-konform (Für FTP-URL ist es konform). Browser, welche die URL-Eingabe überhaupt akzeptieren, wandeln die Authentisierung in einen Authentication-Header um, welcher im Fall von SSL unterwegs natürlich nicht sichtbar ist.
Gruss, Othmar
EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail
Sogar auch der Reverse-SSL-Proxy, VPN mit Bridge uvm. ist bereits alles hier im Forum beschrieben: "man kann" ja!
Aber man kann das nicht aufrichtig behaupten, das individuell jedem mit allen Risiken&Nebenwirkungen erklären zu können..
Mein Prinzip als Hersteller ist da: gescheit oder garnicht.
Ist diese Konstellation so auch bei der hier beschriebenen Anleitung gegeben?
Zugegeben, es bedarf immer noch einem gewissen Aufwand und kostet etwas, es müsste jemand also schon absichtlich Interesse an einer bestimmten Person/ Haus haben. Script Kiddies sind noch aussen vor.
Aber noch ein Wort zur herrlichen Sicherheit und Erklärungsbedürftigkeit von SSL:
- Wie erklärt man dem Anwender, das er zwar immer ein "untrusted" Zertifikat zu bestätigen hat, aber bitte nicht wenns grad ein MITM Angriff ist?
- Oder dem Betreiber/Admin das er mind. alle 2J einen mords-heckmeck machen muss und mid. 100 Steine für das Zertifikat brennen, damit das wirklich sauber ist (Wenn sich dann nicht grad eine von den ach so tollen CA's hat hacken lassen oder eine andere komische Spiele treibt)
Da brauchen wir garnicht über die Sicherheit von PPTP zu diskutieren, mit entsprechendem Aufwand macht der richtige Angreifer das per gängigem Rootkit einfach auf dem PC selbst (deswegen ist der USB-Stick zum booten, wenn mans wirklich ernst meint, bei Tante Hilde garnicht so falsch)
Nein, bei OpenVPN (und IPSec was jedoch way to kompliziert ist) weil jedes packerl unabhängig von AuthZ nur verarbeitet wird so die - ich nenne es mal - äussere Signatur stimmt.
Ich zitiere mal aus der OpenVPN-Doku:
Code:
The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
DoS attacks or port flooding on the OpenVPN UDP port.
Port scanning to determine which server UDP ports are in a listening state.
Buffer overflow vulnerabilities in the SSL/TLS implementation.
SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar