Unmö*g*lichkeit des Tages

[dedlfix]

Tach!

"Change your password so it no longer contains any Unicode characters."

dedlfix.

[Der Martin]

Hallo,

"Change your password so it no longer contains any Unicode characters."

hahaha, ich schmeiß mich weg!

Was bleibt denn dann noch? Hat EBCDIC vielleicht Zeichen, die nicht in Unicode enthalten sind? Nö.
Hmm, die Auswahl wird sehr dünn.

Abgesehen davon: Ein Trauerspiel, dass Microsoft diese Information nur Browsern mit aktiviertem JS zugänglich machen will.

So long,
 Martin

[Google weiß alles]

Abgesehen davon: Ein Trauerspiel, dass Microsoft diese Information nur Browsern mit aktiviertem JS zugänglich machen will.

Drei (3) Trauerspiele. Quasi wie in Bayreuth.

1. Der Anlass der Nachricht.
2. Überschrift und Inhalt der Nachricht.
3. JS als Voraussetzung für die Kenntnissnahme einer sicherheitsrelevante Information. (Verfügbarkeit gehört zur Datensicherheit)

[ralphi]

Hi all,

Verstädnisfrage:
Die Authentifizierung findet doch am Server statt - nicht beim Client (Outlook)
Wird das Passwort nicht erst als Klartext -> danach wie alles SSL verschlüsselt zum Server gesendet?
Demnach kann es doch dem Client egal sein, was er für Zeichen sendet?

Viele Grüße aus LA
ralphi

[Christian Kruse]

Hallo ralphi,

Wird das Passwort nicht erst als Klartext -> danach wie alles SSL verschlüsselt zum Server gesendet?

Depends. Es gibt verschiedene Authentifizierungsverfahren, aber plain ist in der Tat das am häufigsten verwendete.

Demnach kann es doch dem Client egal sein, was er für Zeichen sendet?

Na, und in welcher Kodierung soll der Client das schicken? ;-) CP850? Windows-1252 oder doch lieber UTF-8/16/32? EBCEDIC?

IMAP4 sieht UTF-8 vor, aber du siehst, hier kann man durchaus was falsch machen.

LG,
CK

[dedlfix]

Tach!

Verstädnisfrage:

Verstehen kann man das Problem nur, wenn man genau weiß, was da passiert. Ein allgmeines "wie es laufen könnte oder normalerweise läuft" ist da nicht hilfreich. Das Problem liegt wohl bei der Verarbeitung auf dem Server und das ist Closed Source, also kaum bis sehr schwierig nachschaubar. Ich denke nicht, dass es einen großen Erkenntnisgewinn für andere Situationen gibt als: beim Testen auch Extremsituationen mit ungebräuchlichen Zeichen nicht auslassen.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Das Problem liegt wohl bei der Verarbeitung auf dem Server [...]

Eher bei der Verarbeitung am Client. Outlook 2016 ist ein Client, und das Problem tritt lt Artikel auf wenn man mit Outlook einen IMAP-Server verwendet und im Passwort ein anderes Zeichen als im ASCII-Satz enthalten.

Microsofts Email-Server heißt Exchange ;-)

LG,
CK

[dedlfix]

Tach!

Das Problem liegt wohl bei der Verarbeitung auf dem Server [...]

Eher bei der Verarbeitung am Client.

Ahja, der Client, wenn man richtig liest, aber am Rest ändert sich nichts, ist ja auch Closed Source.

dedlfix.

[pl]

Ich frag mich, warum die Zeichenkodierung überhaupt eine Rolle spielt.

Weil: Sowohl Übertragung als auch sämtliche Chiffre-Algorithmen arbeiten byte-orientiert.

PS: Ist mir klar, dass Ihr das hier wieder nicht versteht, den Unterschied zwischen byte- und charactersemantic. Ich seh's dann an der Bewertung meiner Beiträge.

[ralphi]

Hi all,

ich dachte erst auch nur an die ASCII Zahl nicht an das Zeichen.
Dem ist wohl nicht so ?!

Viele Grüße aus LA
ralphi

[Der Martin]

Hallo,

ich dachte erst auch nur an die ASCII Zahl nicht an das Zeichen.

was meinst du damit?

ASCII ist ein Zeichensatz, der auch gleich die Codenummern der Zeichen festlegt. Nämlich 0x20..7F für druckbare Zeichen und unter 0x20 für Steuerzeichen. ASCII ist als Untermenge in fast allen anderen Zeichensätzen und Codierungen enthalten.

Was nach deinem Verständnis nun eine "ASCII Zahl" ist, verstehe ich nicht ganz. Vielleicht der numerische Code eines Zeichens?

So long,
 Martin

[ralphi]

Hi Martin,

ASCII ist ein Zeichensatz, der auch gleich die Codenummern der Zeichen festlegt. Nämlich 0x20..7F für druckbare Zeichen und unter 0x20 für Steuerzeichen. ASCII ist als Untermenge in fast allen anderen Zeichensätzen und Codierungen enthalten.

Meinte ich ja - Zeichentabellen ASCII (7 bit) ist nur "mein Alias" für Zuordnung Zahl -> Zeichen.

Wie Christian schon schrieb:gibts auch 2 Byte bc c3 - wobei der Client anscheinend nur eins sendet: c3? Und den Rest untern Tisch kehrt.

Viele Grüße aus LA
ralphi

[Christian Kruse]

Hallo ralphi,

Wie Christian schon schrieb:gibts auch 2 Byte bc c3

Das ist ein UTF-8-kodiertes ü. c3 ist das gleiche in Latin1.

wobei der Client anscheinend nur eins sendet: c3? Und den Rest untern Tisch kehrt.

Was genau Outlook da macht wissen wir nicht. Das ist nur eine (IMHO naheliegende) Vermutung.

LG,
CK

[Christian Kruse]

Hallo pl,

Weil: Sowohl Übertragung als auch sämtliche Chiffre-Algorithmen arbeiten byte-orientiert.

Klar, aber ob ich bc c3 oder c3 schicke macht durchaus einen Unterschied. Entweder kommt beim Server bc c3 an (utf-8) oder c3 (latin1).

PS: Ist mir klar, dass Ihr das hier wieder nicht versteht, den Unterschied zwischen byte- und charactersemantic. Ich seh's dann an der Bewertung meiner Beiträge.

Dunning-Kruger at its finest.

LG,
CK

[Der Martin]

Hallo,

Die Authentifizierung findet doch am Server statt - nicht beim Client (Outlook)

ja, natürlich.

Wird das Passwort nicht erst als Klartext -> danach wie alles SSL verschlüsselt zum Server gesendet?

Von verschlüsselter Übermittlung (SSL) ist im Microsoft-Artikel keine Rede, aber ich gehe davon aus, dass die auch meist verwendet wird. Das hat aber mit dem beschriebenen Passwort-Problem AFAIS nichts zu tun.

In dem Fall ist deine Annahme aber möglicherweise falsch. Denn bei verschlüsselten Verbindungen zum Mailserver gibt es zwei verschiedene Verfahren.

Entweder wird erst eine verschlüsselte Verbindung (SSL/TLS) aufgebaut, und zwar wie beim Web-Browser anonym, also ohne Benutzernamen und Kennwort. Und dann erst sprechen Client (Outlook) und Server über diese Verbindung IMAP. In diesem Fall werden also auch die Anmeldedaten schon verschlüsselt übertragen.

Oder die Anmeldung beim Mailserver geschieht zunächst offen, also unverschlüsselt, und danach erst gibt der Client das Kommando STARTTLS, worauf beide (Client und Server) zu verschlüsselter Übertragung wechseln. In dem Fall sind Benutzername und Passwort im Klartext sichtbar, nur der eigentliche Postfach-Zugriff ist verschlüsselt.

Demnach kann es doch dem Client egal sein, was er für Zeichen sendet?

Ja, ist es auch. Es muss nur auf dieselbe Art codiert sein, wie es auch der Server beim Festlegen des Passworts macht.

So long,
 Martin