Verschlüsselter Login mit uc

[Thomas (Gast)]

Hallo zusammen,

nur eine kurze Frage ob ich hier nicht eventuell auf dem Schlauch stehe.
Ich hätte gerne eine Verbindung mit einem uC über TCP/IP hergestellt.
Als Protokoll wollte ich simples xml über http nehmen, und ein Login 
sollte in etwa so aussehen:

<login>
<name>hans</name>
<pass>wurst</pass>
</login>

(denkt euch das HTTP 1.1 GET Zeugs einfach dazu!)

Nun möchte ich aber das Passwort nicht im Klartext über die Leitung 
schicken https aber ist für einen uC schwierig.

Schicke ich den Passworthash über die Leitung bin ich leider anfällig 
für eine Replay-Attacke (jemand der alles mitsnifft und dann genauso 
nochmal abspielt!).

Mein momentaner Ansatz wäre dass Client und Server gemeinsamen einen 
Diffie-Hellman-Schlüsselaustausch durchführen, damit auf eine gemeinsame 
Zahl kommen die NICHT über die Leitung geht.

Mit dieser gemeinsamen Zahl könnten beide das ihnen bekannte 
Klartext-Passwort (wurst) XORen, und danach mit BASE64 noch in einen 
Zeichensatz umwandeln der über die Leitung geht.

Als Alternative würde mir noch einfallen (Security by Obscurity) dass 
zwar direkt der Passworthash über die Leitung geschickt wird, davor aber 
noch mit irgendeinem sowieso bekannten Geheimniss vermatscht wird (z.B. 
IP-Adresse des Clients).
Das ist etwas unkomplizierter als ein Diffie-Hellman, aber natürlich 
auch deutlich unsicherer.
(wobei 100% Sicherheit definitiv NICHT nötig ist in meinem 
Anwendungsfall. Es sollte nur nicht absolut lächerlich offensichtlich 
unsicher sein!)

Fällt euch eine einfache Lösung ein wie zwei Parteien, die ein Passwort 
jeweils im Klar-, und Geheimtext kennen, sich bestätigen können dass dem 
so ist, ohne dass jemand der auf der Leitung mitsnifft einfach genau die 
gleiche Konversation wieder durchführen kann und somit auch wieder die 
gleichen Rechte hat?

Mfg,
Thomas

[Peter II (Gast)]

Thomas schrieb:
> Fällt euch eine einfache Lösung ein wie zwei Parteien, die ein Passwort
> jeweils im Klar-, und Geheimtext kennen, sich bestätigen können dass dem
> so ist, ohne dass jemand der auf der Leitung mitsnifft einfach genau die
> gleiche Konversation wieder durchführen kann und somit auch wieder die
> gleichen Rechte hat?

dafür ist DH schon das richtige. Oder können beide Parteien z.b. ein 
Private und Public key bekommen? Dann könnte man jeweils die Daten für 
den andere Teilnehmer verschlüsseln. Man muss nur vorher die Public-Keys 
austauschen.

Bei DH kann man per Man-in-the-middle immer noch alles mitlesen. Die 
Frage ist ob das für die Relevant ist.

[Martin (Gast)]

Hallo Thomas.

Der Server schickt auf Anfrage eine RND zum Client und der 
"verwurschtelt" das mit dem Passwort? Auf dem Server wird es mit RND 
wieder "entwurschtelt" und wenn es passt darf der Client zugreifen.
Gut wenn man sich jetzt MITM klemmt könnte man theoretisch einmal rein 
...
Da hilft dann nur ein shared Secret auf beiden Seiten.


Martin

[Thomas (Gast)]

@Peter:
Ich dachte DH wäre gegen MITM vollkommen sicher da beide Parteien 
unabhängig voneinander ein Geheimniss ermitteln welches NICHT NIE über 
die Leitung geht?
Irre ich?

@Martin:
Dass mit dem Round und verwurschteln klingt gut.
Wäre wohl in etwa der Sicherheitsstand der ausreichend ist.
Ein Shared Secret auf beiden Seiten habe ich ja quasi.
Da kann ich austauschen was ich will.

Danke für die Ideen schonmal!

Thomas

[Peter II (Gast)]

Thomas schrieb:
> @Peter:
> Ich dachte DH wäre gegen MITM vollkommen sicher da beide Parteien
> unabhängig voneinander ein Geheimniss ermitteln welches NICHT NIE über
> die Leitung geht?
> Irre ich?
ja

DH sichert nur ab das niemand etwas mitlesen kann (ohne aktiv 
einzugreifen). Es sichert aber nicht ab mit wem man redet. Aus dem Grund 
gibt es doch für https noch die Zertifikate.

[apr (Gast)]

http://de.wikipedia.org/wiki/HTTP-Authentifizierung#Digest_Access_Authentication 
?

[♪Geist (Gast)]

apr schrieb:
> http://de.wikipedia.org/wiki/HTTP-Authentifizierung#Digest_Access_Authentication
> ?

Base64 ist genau das, was er nicht haben möchte.

Thomas schrieb:
> Schicke ich den Passworthash über die Leitung bin ich leider anfällig
> für eine Replay-Attacke (jemand der alles mitsnifft und dann genauso
> nochmal abspielt!).

[Thomas (Gast)]

@ Peter II:

Ja, soweit stimmt das natürlich.
Aber eine Replay Attacke würde doch auch verhindert werden da sich die 
beiden Parteien ihre Zufallszahlen ja jedesmal neu ausdenken, das meinte 
ich...

Mit dieser Zufallszahl (die jedes Mal neu ermittelt wird, dank DH) 
verschlüsseln beide Parteien das (ihnen bekannte) Klartextpasswort.
Meine Sicherheit besteht also darin dass beide Parteien dass Kenntwort 
kennen.

Eine Replay würde ja verhindert werden da beim nächsten Mal Server und 
Client sich eine neue Zufallszahl ausdenken, und der somit der erzeugte 
Hash der da letzte Mal verwendet wurde nicht mehr stimmt.
Neu hashen kann aber der Angreifer nicht da er zwar den DH durchführen 
kann, aber das Klartext Passwort für das Hashen nicht hat.

Und aus dem zuletzt mitgeschnittenen Hash das Klartextpasswort ermitteln 
kann er nicht, da ja der ermittelte DH Schlüssel mit dem dass Passwort 
gehast wurde nie über die Leitung ging.
Korrekt?

Thomas

[apr (Gast)]

♪Geist schrieb:
> Base64 ist genau das, was er nicht haben möchte.

Verstehe die Antwort nicht. Der Link geht auf Digest-Authentification:
Server schickt dem Client eine Zufallszahl n. Der Client bildet aus 
dieser und dem Kennwort einen Hash und schickt den zurück. Das Passwort 
geht nicht im Klartext über die Leitung und es ist deutlich weniger 
Aufwand als DH. Und auf den HTTP hatte gelinkt um daraufhinzuweisen, 
dass HTTP das schon kann - dann muss man keine Pseudo XML Dokumente 
verschicken.

[Thomas (Gast)]

@apr:
Der Link war etwas verwirrend weil Aufgrund der Bildschrimauflösung die 
Basic Authentifizierung oben steht. DA klingt ziemlich genau wie das was 
ich brauche. Vielen Dank!

Thomas