debianforum.de

Meillo hat geschrieben:Das geht ja in Richtung Pubkey-Auth

Ja. Nur dass der Server nicht nur den PubKey, sondern auch den mit Passwort verschlüsselten PrivKey verwahrt und zur Anmeldung an den Anwender ausliefert. Ist bestimmt nicht optimal. Aber es muss doch Entwickler geben, die das als Vorteil sehen auch wenn es für den Anwender auf den ersten Blick nicht unterscheidbar ist. Vorteil ist, dass das Passwort nie übertragen wird. Dass der Anwender seinen PrivKey selbst verwahrt erwarte ich ja gar nicht. Die Webanwendung wie dieses Forum soll ja auf jeden javascriptfähigen Browser laufen. PrivKeys selbst zu verwalten ist echt mühsam vor allen auf mobilen Endgeräten.

uname hat geschrieben:

01.02.2019 10:19:25

Meillo hat geschrieben:Das geht ja in Richtung Pubkey-Auth

Dass der Anwender seinen PrivKey selbst verwahrt erwarte ich ja gar nicht.

Das waere aber das was er tun sollte. Seine EC-Karte hinterlegt man ja auch nicht bei der Bank und seine Haustuerschluessel bekommt man auch nicht mit der Post zur Tuer geschickt. Ich befasse mich dabei aber natuerlich mehr mit den Wurzeln der Probleme. Wenn wir die strukturellen Fehler halt beibehalten, dann werden uns alle angekuendigten ``Loesungen'', die bloss an den Auswirkungen rumfeilen, ein paar Jahre spaeter wieder auf die Fuesse fallen. Natuerlich erfordert es grundsaetzliche Software- und Bedienaenderungen, wenn man am Grundsaetzlichen etwas aendert, das aber doch nur weil man es bislang immer falsch gemacht hat. Zu sagen, dass ich alles wie bisher machen will, es aber sicher sein soll, kann nicht funktionieren.

Die Webanwendung wie dieses Forum soll ja auf jeden javascriptfähigen Browser laufen.

... und auf jedem nicht JS-faehigen Browser, bitte! Ich haette jedenfalls ein Problem, wenn es nicht mehr mit w3m nutzbar waere ... bloss weil der Login JS benoetigt, damit er etwas sicherer wird (scheinbar, weil die Leute dann JS fuer das Forum aktivieren muessen und damit weitere Risiken entstehen), wohingegen ich mit ssh- und gpg-Pubkeys ein noch viel besseres Verfahren anbieten koennte. Ich will meine spezielle Situation nicht zu wichtig machen, mir geht es um das grundsaetzliche Vorgehen, dass man die Probleme nicht an der Wurzel loest, sondern, weil man dem Mainstream nichts zumuten will, immer noch mehr Technologien, noch mehr Komplexitaet, noch mehr Code drauf packt und meint, damit wuerde man es besser machen. Meiner Meinung nach ist das die falsche Richtung, weil dadurch bloss noch immer mehr Sicherheitsrisiken entstehen. Mehr Sicherheit erlangt man, wenn man reduziert und die richtigen Dinge macht. Wenn man es bisher falsch gemacht hat, muss man es zukuenftig eben richtig machen ... und den Leuten sagen, dass und warum es falsch war und warum es jetzt anders sein muss und warum es jetzt nicht mehr so bequem (d.h. naiv) wie frueher sein kann. Das erfordert aber einen Fehlerkultur und Ehrlichkeit, die nicht vorhanden ist.

PrivKeys selbst zu verwalten ist echt mühsam vor allen auf mobilen Endgeräten.

Eben da muss man ansetzen. Das muss einfacher werden. Man muss dort die zufaellige Komplexitaet reduzieren (um Fred Brooks' Worte zu verwenden), man darf aber nicht versuchen, die essenzielle Komplexitaet reduzieren zu wollen. Die essenzielle Komplexitaet ist die Komplexitaet des Systems selbst, also der Fachdomaene, die muss man verstehen, um angemessen damit arbeiten zu koennen. Man muss z.B. das Wahlsystem an sich verstehen, um angemessen waehlen zu koennen. Es funktioniert nicht, bloss ein Kreuz zu machen und zu denken, dass damit alles gut waere. So wird das aber verkauft: Vertrauen ist ueberhaupt kein Problem, Sicherheit ist ueberhaupt kein Problem, die Software und die Firmen machen das fuer dich. Die zufaellige Komplexitaet, die nur der Umsetzung innewohnt, wie beispielsweise irgendwelche Buerokratie bei der Stimmabgabe, die keinen Beitrag zum Wahlsystem selbst leistet, oder unnoetige Klickerei oder zusammengehoerende Information an verschiedenen Stellen abzulege, etc., die sollte reduziert werden. Diese Unterscheidung der zwei Komplexitaetsarten und der gegensaetzliche Umgang mit ihnen sollte viel mehr beachtet werden.

Danke für deine Ausführungen. Natürlich hast du Recht. Der Vorteil von Webanwendungen ist aber, dass sie in jeden Browser auf jeden Betriebssystem funktionieren. Man sollte endlich überhaupt anfangen und nicht die 100%-Lösung suchen.

Webanwendungen sollen in jedem Browser auf jeden Betriebssystem laufen und der Anwender möchte weder einen Key kopieren noch ein OTP verwenden. Es wird sich somit nie was ändern, da PrivKeys und OTP (z. B. Smartphone) immer umständlich sind.

Vergleichsfall PrivateBin (jedoch nur synchrone Verschlüsselung per Javascript):
Schau dir Anwendung https://privatebin.net/ an, die für die Verschlüsselung per Javascript https://github.com/bitwiseshiftleft/sjcl verwendet. Natürlich kann man Javascript kritisieren. Aber diese Form einer Verschlüsselung ist weit besser als gar keine. Natürlich muss man auf die Risiken hinweisen siehe "What it doesn't provide" https://privatebin.info . Es wäre aber denkbar in diesen Fall synchrone Verschlüsselungsroutine und Hosting auf zwei Provider zu verteilen.

Meillo hat geschrieben:

01.02.2019 10:58:32

Seine EC-Karte hinterlegt man ja auch nicht bei der Bank

Es gibt aber genug Menschen, die ihre Kreditkarte im Telefon hinterlegen, zwecks mobile Payment. Das finde ich mindestens genauso gruselig.

Was EC-Karten angeht, so hat die Bank natürlich eine Kopie der EC-Daten. Ich würde den Banken sogar zutrauen, daß es keine Public-Private-Key Infrastruktur am Geldautomaten gibt, bei der die Bank nur den public Key kennt und auf der EC-Karte der private Key sitzt. Das EC-Kartensystem ist ja juristisch für "sicher" erklärt worden und Juristen müssen es ja wissen.

uname hat geschrieben:

01.02.2019 11:15:13

Man sollte endlich überhaupt anfangen und nicht die 100%-Lösung suchen.

Man sollte auf jeden Fall die im Moment als 100% geltende Lösung suchen. Wenn ich von vorn herein weiß, daß eine Lösung nur 99% ist, dann weiß ich auch, daß einer von 100 am Ende der gelackmeierte ist. Und da ich dieser eine nicht sein will, lehne ich solche Lösungen von vorn herein als völlig unbrauchbar ab. In dem Fall sollte man gar nicht erst anfangen.

MSfree hat geschrieben:Man sollte auf jeden Fall die im Moment als 100% geltende Lösung suchen.

Daher sind unverschlüsselte E-Mail so erfolgreich. Die 100%-Lösung wurde auch da noch nicht gefunden.

@Meillo @MSfree
Zu EC-Karten habe ich folgendes gefunden. Der Standard ist scheinbar von 2011:
https://www.emvco.com/terms-of-use/?u=/ ... 923900.pdf

uname hat geschrieben:

01.02.2019 11:39:10

Daher sind unverschlüsselte E-Mail so erfolgreich.

Unverschlüsselt Email ist so erfolgreich, weil es funktioniert.

Wenn du einen sinnvollen Vorschlag machen kannst, wie man Email einfach verschlüsseln kann, dann nur raus damit. Transportverschlüsselung gibt es bereits flächendeckend. Und für End-to-End brauchst du immer eine Public-Private-Key Infrastuktur und die wird von einer deutlichen Mehrheit, die weit über 90% liegt, als kompliziert empfunden, hat sich daher auch nie durchsetzen können. Ich selbst nutze auch keine Mail-Verschlüsselung, ich habe das nie eingerichtet, weil es schlicht sinnlos ist. Da kann man sich auch gleich komplett von Email verabschieden. Ich kenne keinen einzigen, dem ich verschlüsselte Mails schicken könnte und mir werden auch nur unverschlüsselte Mails geschickt, nach einem öffentlichen Schlüssel zwecks Mailverschlüsselung hat mich auch nich nie jemand gefragt. Folglich wird das nichts.

Auch hier, es könnte so einfach sein. Seit mehr als einem Jahrzehnt wird über die Killeranwendung des E-Personalausweises gesucht. Als Speicher für private Keys wäre der geradezu ideal und supereinfach in der Anwendung (NFC läßt grüßen) und vor allem, jeder hat so eine Plastikkarte.

Aber will man wirklich eine staatlich kontrollierte Infrastruktur?

Bei E-Mail könnte man verschlüsselte Dateianhänge verwenden. Ob die Personalausweise per NFC mit Android und iOS funktionieren weiß ich nicht. Nur da der Anwender Smartphones als unsicher ansieht ist der Sicherheitsvorteil aus Anwendersicht auch eher gering. Und einen Leser für den Ausweis-PC will niemand kaufen oder rumschleppen. Keine 100% Sicherheit und daher bleibt alles beim alten.

uname hat geschrieben:

01.02.2019 12:08:10

Ob die Personalausweise per NFC mit Android und iOS funktionieren weiß ich nicht

Mit einer entsprechend programmierten App(clication) wäre das kein Problem.

Ich sehe in einer Public-Private-Key Infrastruktur aber noch ganz andere Probleme. Im Grunde genommen sind diese Keys auch nicht mehr wert als Paßwörter, nur daß sie in einer Datei stecken und länger als Paßwörter sind. Daraus ergibt sich aber die selbe Problematik mit den Keys wie bei Paßwörtern, Ist der private Key erst kompromitiert, mußt du ihn ändern, mit allen damit verbundenen Konsequenzen:

So mußt du z.B. alle auf deinem Rechner bzw. Server befindlichen verschlüsselten Mails mit dem alten Key entschlüsseln und entweder mit dem neuen Key wieder verschlüsseln oder unverschlüsselt abspeichern.

Du müßtest beim E-Perso den neuen Key eintragen lassen, weil man ja nicht selbst auf den Perso schreiben darf.

Du brauchst wie bei Paßwörtern einen Schlüssel pro Anwendungszweck.

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

MSfree hat geschrieben:

01.02.2019 12:19:46

Ich sehe in einer Public-Private-Key Infrastruktur aber noch ganz andere Probleme. Im Grunde genommen sind diese Keys auch nicht mehr wert als Paßwörter, nur daß sie in einer Datei stecken und länger als Paßwörter sind.

Sie unterscheiden sich in der Art, dass das Geheimnis nie uebertragen werden muss, sondern man macht die Pruefung per Challenge-Response-Verfahren. Das ist ein entscheidender Vorteil.

Ausserdem sind sie asymetrisch, was Verschluesselung und Signierung zulaesst, ohne dass die Gegenstelle dein Geheimnis kennt. Mit Passwoertern geht das nicht.

Daraus ergibt sich aber die selbe Problematik mit den Keys wie bei Paßwörtern, Ist der private Key erst kompromitiert, mußt du ihn ändern, mit allen damit verbundenen Konsequenzen:

[...]

Du brauchst wie bei Paßwörtern einen Schlüssel pro Anwendungszweck.

Das ist korrekt, aber man kann Schluesselhierarchien aufbauen, bei denen dann nur Teile tiefer Ebenen kompromitiert sind, die hoeheren Ebenen aber nicht in Mitleidenschaft gezogen werden. Per Web-of-Trust kann man Vertrauen vererben. Diese Moeglichkeiten hat man mit Passwoertern gar nicht.

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

Meillo hat geschrieben:

01.02.2019 23:00:44

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

Man kann das Handling von Schlüsseln durchaus etwas einfacher gestalten, bzw. mehr in die eingeübte Praxis integrieren.
Vor ein paar Jahren bin ich mal auf einen Maildienst aufmerksam gemacht worden, der "einfache Verschlüsselung" für Outlook-Benutzer anbot. (Weiß nicht mehr, wie die hießen. Saßen in Hannover, iirc.)
Das war vom Workflow her kaum eine Umstellung für die User. Das Problem dabei war, der private Schlüssel lag auf deren Server ::sich-vor-die-Stirn-klatsch-Smilie::

Besser macht das turtl (allerdings nicht im Bereich Email). Hier wird im Client auf Grundlage handelsüblicher Credentials (Username und Passwort) ein Schlüsselpaar erstellt und benutzt. Der User macht also das, was er sonst auch immer macht, unter der Haube wird aber fleißig verschlüsselt und zwar im Client. Man kann dann innerhalb des Systems auch weitere, abgeleitete PubKeys erzeugen (wiederum repräsentiert durch ein Nutzername-Passwort-Paar), um Inhalte zu teilen.

novalix hat geschrieben:

02.02.2019 10:52:19

Meillo hat geschrieben:

01.02.2019 23:00:44

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

Man kann das Handling von Schlüsseln durchaus etwas einfacher gestalten, bzw. mehr in die eingeübte Praxis integrieren.

Das meine ich mit der Unterscheidung von zufaelliger und essenzieller Komplexitaet. Die zufaellige Komplexitaet muss man schon reduzieren. Da ist noch viel Luft nach oben. Das sollte man tun. Man kann es aber nicht einfacher machen als die essenzielle Komplexitaet der Fachdomaene nun eben ist.


Beispielsweise kann man Autofahren einfacher machen indem man Automatik- statt Schaltgetriebe verwendet (zufaellige Komplexitaet), ebenso kann man wartungsaermere Elektroantriebe statt Verbrennungsmotoren verwenden (zufaellige Komplexitaet), aber man kann nicht die Verantwortung des Fahrzeugfuehrers loswerden (essenzielle Komplexitaet) man kann nicht die Interaktion mit anderen Verkehrsteilnehmern loswerden (essenzielle Komplexitaet). Man kann die Wegfindung z.B. mit Navis vereinfachen oder komplett auslagern (zufaellige Komplexitaet), aber man kann nicht die Angabe des Fahrziels auslagern (essenzielle Komplexitaet).

Fred Brooks' beschreibt das AFAIR in ``No Silver Bullet''. Diese explizite Sicht auf die zwei so unterschiedlichen Arten von Komplexitaet sollte viel mehr eingenommen werden.