PHP Ich verstehe den Random Salt nicht

[ice-breaker]

ja solange nur der Client sich beim Server authentifiziert ist das in Ordnung, ich bin gedanklich aber eben den vollen Weg gegangen, dass sich auch der Server noch beim Client authentifizieren muss.
Und dann müsste der Client eben von jedem Dienst den public-Key haben.

 

[Trainmaster]

Wie sieht das in der Praxis aus. Als Nutzer muss man sich ein Schlüsselpaar erstellen und den Public-Key demjenigen Server mitteilen, bei dem man sich registrieren will (Wieso sollte die ganze Welt meinen Public-Key kennen? Einfach so? ...). Verliert man aus Versehen den Private-Key, darf man bei allen Seiten seinen Public-Key wieder ändern. Usability... nein danke

 

[1668mib]

@ice-breaker: Naja, Server authentifizieren sich ja schon bei den Clients bei z.B. HTTPS-Verbindungen... geschieht alles automatisch ohne dass man es merkt.
Da dein Browser nicht jeden Public-Key eines Servers kennen kann, kommen Trust-Center zum Einsatz. Diese signieren Public-Keys anderer und bürgen, dass der Public-Key wirklich der Person/Einrichtung gehört (Nachweis über z.B. Post-Ident oder pesönliches Erscheinen beim Center). Jetzt ist nur noch das Vertrauen in die Trust-Center nötig und man muss deren Schlüssel kennen. Die Browser bringen diese i.d.R. schon mit.

Aber du hast schon Recht: Grundsätzlich sollte auch der Client prüfen, ob es sich um den richtigen Server handelt. Bei SSH wird in der Regel ja beim ersten Verbindungsaufbau gefragt, ob man dem Server vertraut und der Fingerprint des Servers anschließend gemerkt.

@Trainmaster: Die Wahrscheinlichkeit, einen Private-Key zu verlieren, hängt vom User selbst ab. Dir ist die Technologie der Sicherungskopien bekannt?
Sich zig Passwörter auf zig Seiten zu merken ist auch nicht wirklich leicht, nicht grundlos haben viele Leute das selbe unsichere Passwort auf vielen Seiten. Wie die Passwörter gespeichert werden, weiß man selbst auch nicht. Dem Server das eigene Passwort zu schicken verlangt einiges an Vertrauen. Woher weiß man, ob die Passwörter nicht im Klartext gespeichert werden?

Wenn du nur ein Passwort hast, und du vergisst dieses, darfst du bei allen Seiten übrigens dein Passwort wieder ändern...

Und wenn du nicht verstehst, warum die ganze Welt deinen Public-Key kennen sollte, dann sehe ich schon, dass du offensichtlich von dem Verfahren nicht viel Ahnung hast...

Und bei vernünftiger Implementierung braucht man bei Public-Key-Verfahren ehrlich gesagt nichts ändern. Wichtig ist nur, dass der Server sicher sein muss, dass der Public-Key zum User gehört. Das ist z.B. auch über Trust-Center möglich. Dann könnte man bei der Authentifizierung einfach die signierte Zufallszahl samt von einem Trust-Center signierten Public-Key übermitteln.

 

[ice-breaker]

@ice-breaker: Naja, Server authentifizieren sich ja schon bei den Clients bei z.B. HTTPS-Verbindungen... geschieht alles automatisch ohne dass man es merkt.

theoretisch ja, bringt aber nix bei Phising-Seiten, wenn ein User nicht auf die URL achtet.
Aber wir sind uns ja trotzdem einig, die Usability von Public-Key-Authentifizierung ist einfach nicht wirklich dolle.

 

[1668mib]

Ja... wobei man auch sagen muss, dass Phishing bei Public-Key eigentlich wiederum wenig bringt, außer man macht es in Form eines Man-in-the-Middle-Angriff.

Also ich will mich z.B. bei meiner Bank anmelden, bin aber bei der falschen Seite. Die falsche Seite muss jetzt den Anmeldevorgang bei meiner Bank starten, und mir dann die Zufallszahl schicken. Ich authentifiziere mich bei der falschen Seite und schicke denen die signierte Zahl. Die falsche Seite kann nun - ohne meinen Private-Key zu kennen - sich bei der Bank in meinem Namen anmelden.

Insofern ist es ja wichtig, dass man auch selbst prüft, ob der Server echt ist. Aber diese Problematik hat den Ursprung nicht im Public-Key-Verfahren, sondern beim Menschen. Public-Key-Systeme bringen ja sogar Methoden mit, um Phishing-Angriffe deutlich zu erschweren.

 

[Trainmaster]

In der Tat habe ich mich mit diesem Verfahren vorher noch nie beschäftigt. Dennoch vermag ich das Prinzip verstanden zu haben. Die Tatsache, dass ein jeder mit dem öffentlichen Schlüssel den Besitzer des privaten Schlüssels authentifizieren kann impliziert doch nicht, dass die ganze Welt den öffentlichen Schlüssel kennt. Es ist doch völlig ausreichend, wenn ich den Public-Key jenen System offenlege, mit denen ich kommunizieren möchte, bspw. Facebook, Google, StudiVZ, Computerbase etc.

Angenommen die ganze Welt kennt meinen Public-Key. Folglich müsst es ein rießige Datenbank mit allen Public-Keys geben. Nur so kann die ganze Welt meinen Public-Key kennen. Wiederum müsste jede noch so kleine Webseite, die auf eine Public-Key-Authentifizierung zurückgreift, diese Datebank durchkämmen. Es reicht doch völlig aus, wenn jede Webseite ihre eigene Datenbank mit Public-Keys hat.

Wie gesagt, ich sehe einen Unterschied zwischen Öffentlich machen für das jeweilige System und der ganzen Welt, die meinen Public-Key kennt. Den Public-Key verstehe ich im Sinne von öffentlich machen für ein bestimmtes System, um mit diesem zu kommunizieren. Und nicht öffentlich machen für die ganze Welt, damit einfach mal jeder den Public-Key kennt.

 

[1668mib]

@Trainmaster: Es geht darum, dass dein Public-Key jedem zur Verfügung stehen sollte. Und es gibt Datenbanken mit Public-Keys, z.B. Trust Center.

Ich meinte mit "die ganze Welt kennt" auch nur salopp "den man nicht geheim halten muss". Entschuldigung, dass ich zu viel Interpretationsvermögen vorausgesetzt hatte.

Weil du kannst viel mehr machen mit deinen Private Key. Du kannst auch selbst Dinge signieren (Digitale Signatur). Die Signatur kann nur geprüft werden, wenn der Prüfer auch deinen Public-Key kennt - und weiß, dass er dir gehört.

Es wäre im Grunde optimal, wenn jeder die Public-Keys der anderen kennen würde...

 

[Trainmaster]

Jeder Foren-Betreiber, jeder Shop-Betreiber, der auf eine Public-Key-Authentifizierung setzen würde, müsste deiner Ansicht nach auf Trust Center zurückgreifen. Da würde ich mich als Betreiber richtig freuen ...

Es hat rein gar nichts mit Interpretationsvermögen zu tun, wenn du von "die ganze Welt kennt" auf "den man nicht geheim halten muss" schließt. Das ist eine rein willkürliche Auslegung deinerseits. Denn wenn du sagst, dass der Public-Key ein Schlüssel ist, "den man nicht geheim halten muss", ist es völlig legitim wenn ich sage, dass es reicht, ihn nur denjenigen mitzuteilen, mit denen ich kommunizieren möchte. Zusätzlich beinhaltet deine Aussage "nicht geheim halten muss" zugleich die Möglichkeit, dass man ihn trotzdem geheim halten kann. Bevor du das nächste anderen mangelndes Interpretationsvermögen unterstellst, solltest du auf deine eigenen Aussagen achten. Das ist ja wohl lächerlich.

Außerdem sollten wir wieder auf das Thema zurückkommen: Login-Prozedur bei einer Webanwendung. Du magst zwar argumentieren, dass eine Public-Key-Authentifizierung zeitgemäß wäre, jedoch gibt es allen Anschein nach genug Gründe, welche in diesem Bereich dagegen sprechen. Und es ist ja nicht so, dass das Public-Key-Verfahren in anderen Bereichen keinen Anklang in der breiten Masse findet: Digitale Signaturen, E-Mail-Verkehr, SSL, SSH, VPN ...

 

[1668mib]

Ich halte die aufgezählten Dinge von dir leider nicht für die "breite Masse".

Warum du so Probleme hast mit meiner Formulierung "Den die ganze Welt kennt" hast, ist mir allerdings schleierhaft. Gerade für Digitale Signaturen ist es wichtig, dass ein jeder die Signatur prüfen kann, egal ob du ihn als potentiellen Kommunikationspartner betrachtest.

 

[Trainmaster]

In der Geschäftswelt macht dies ja durchaus Sinn. Jedoch zahle ich doch nicht ernshaft als Privatanwender an ein Trust Center, damit ich mich in irgendwelchen Foren / Online-Shops anmelden kann Wie gesagt: Usability.

Wenn der E-Mail-Verkehr / Digitale Signatur deiner Ansicht nach keine breite Masse erfasst, dann kann ich dir auch nicht helfen.