Login-System: Was sollte SSL verschlüsselt werden?

[HP-Bauer]

Hallo,

ich erstelle gerade für eine HP ein Login-System. Einzelne Unterseiten sind dann nur noch von Mitgliedern abrufbar. Was sollte man mit SSL verschlüsseln? Nur den Login-Vorgang, die Änderung der User-Daten (sprich jeden Austausch mit der Mysql-Datenbank) oder auch die Session-Überprüfung auf jeder Seite? Im Voraus bereits vielen Dank für alle Antworten.

MfG,
HP-Bauer

[Sven Rautenberg]

Moin!

Was sollte man mit SSL verschlüsseln? Nur den Login-Vorgang, die Änderung der User-Daten (sprich jeden Austausch mit der Mysql-Datenbank) oder auch die Session-Überprüfung auf jeder Seite?

Wie sensitiv sind deine Daten? Welcher Schaden entsteht, wenn Unbefugte von ihnen a) Kenntnis erlangen oder b) sie verändern?

- Sven Rautenberg

[King Lully]

Was sollte man mit SSL verschlüsseln? Nur den Login-Vorgang, die Änderung der User-Daten (sprich jeden Austausch mit der Mysql-Datenbank) oder auch die Session-Überprüfung auf jeder Seite?

Alles sollte SSL-gesichert sein. Wo ist das Problem? SSL ist doch über das Protokoll HTTPS so zu sagen gekapselt.

[Nixwisser]

ich erstelle gerade für eine HP ein Login-System. Einzelne Unterseiten sind dann nur noch von Mitgliedern abrufbar. Was sollte man mit SSL verschlüsseln?

Wenn Du schon die Möglichkeit hast, eine SSL-gesicherte Verbindung anzubieten, dann lass' gleich das komplette Angebot darüber laufen. Es gibt keinen Grund, dies nicht zu tun, außer vielleicht, dass eventuell der eine oder andere Adressammel- oder Spamrobot mit SSL nicht umgehen kann.

[wahsaga]

hi,

Wenn Du schon die Möglichkeit hast, eine SSL-gesicherte Verbindung anzubieten, dann lass' gleich das komplette Angebot darüber laufen. Es gibt keinen Grund, dies nicht zu tun, außer vielleicht

... eventuell angebotener großer Binärdaten wie Videos, Audio, große Bilder - die jedes mal en- und wieder dekodieren zu lassen, würde auf beiden Seiten  massiv Ressourcen verbrauchen, selbst wenn die "Sicherheit" dieser Daten das gar nicht erfordern würde.

gruß,
wahsaga

[King Lully]

... eventuell angebotener großer Binärdaten wie Videos, Audio, große Bilder - die jedes mal en- und wieder dekodieren zu lassen, würde auf beiden Seiten  massiv Ressourcen verbrauchen, selbst wenn die "Sicherheit" dieser Daten das gar nicht erfordern würde.

Wie massiv denn? Wir haben es doch mit einer dann symmetrischen Verschlüsselung zu tun.

[wahsaga]

hi,

... eventuell angebotener großer Binärdaten wie Videos, Audio, große Bilder - die jedes mal en- und wieder dekodieren zu lassen, würde auf beiden Seiten  massiv Ressourcen verbrauchen, selbst wenn die "Sicherheit" dieser Daten das gar nicht erfordern würde.

Wie massiv denn?

Erwarte jetzt bitte keine konkreten Zahlen :-)
Wie sehr das die jeweils beteiligten Systeme belastest oder nur mit den Achseln zucken lässt, hängt natürlich auch von deren Ausstattung und Auslastung ab.

Aber mehrere (Dutzend) MB on-the-fly mit bspw. 128 Bit zu ver-/entschlüsseln, ist schon nicht mehr mit einem Fingerschnippen getan. Das mag dem High-End-Gamer-PC, der als Clientrechner fungiert, noch recht egal sein - aber Server sind idR. gar nicht mal _so_ dicke ausgestattet, und die haben nicht nur einen "Kunden" gleichzeitig, sondern bedienen Dutzende oder noch mehr weitgehend parallel. Und die Verschlüsselung erfolgt ja für jede Client-Server-Verbindung mit einem eigens ausgehandelten Schlüssel, also mit "Caching" auf Serverseite is' da nichts.
Und Caching auf Client-Seite (über eine Sitzung hinaus) oder Proxies auch nicht - selbst wenn also Hundert Anforderer hinter dem gleichen Proxy sitzen, diese Daten im Kontext der Gesamtanwendung nicht sicherheitskritisch sind und eigentlich im Normalfall gut vom Proxy gecached werden könnten - wegen SSL kann er nicht, also entsteht bis zum Hundertfachen an Traffic.

Wir haben es doch mit einer dann symmetrischen Verschlüsselung zu tun.

Ändert ja nichts daran, dass beide Seiten die Daten "umrechnen" müssen.

gruß,
wahsaga