Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comm.software.mailreader > #231 > unrolled thread

[mutt] Authentification (Plain)

Started byAndreas Kohlbach <ank@spamfence.net>
First post2017-04-11 13:18 -0400
Last post2017-04-29 11:41 -0400
Articles 10 — 4 participants

Back to article view | Back to de.comm.software.mailreader


Contents

  [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-11 13:18 -0400
    Re: [mutt] Authentification (Plain) Helmut Springer <delta+usenet@lug-s.org> - 2017-04-11 19:33 +0000
      Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-12 17:17 -0400
        Re: [mutt] Authentification (Plain) dseppi@a1.net (David Seppi) - 2017-04-13 10:23 +0000
        Re: [mutt] Authentification (Plain) Thomas Hochstein <thh@inter.net> - 2017-04-14 11:36 +0200
          Re: [mutt] Authentification (Plain) dseppi@a1.net (David Seppi) - 2017-04-14 13:43 +0000
          Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-14 15:58 -0400
            Re: [mutt] Authentification (Plain) Helmut Springer <delta+usenet@lug-s.org> - 2017-04-14 20:54 +0000
            Re: [mutt] Authentification (Plain) Thomas Hochstein <thh@inter.net> - 2017-04-29 14:42 +0200
              Re: [mutt] Authentification (Plain) Andreas Kohlbach <ank@spamfence.net> - 2017-04-29 11:41 -0400

#231 — [mutt] Authentification (Plain)

FromAndreas Kohlbach <ank@spamfence.net>
Date2017-04-11 13:18 -0400
Subject[mutt] Authentification (Plain)
Message-ID<871ssyq2vx.fsf@usenet.ankman.de>
Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert
das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz

| Authentification (Plain)

Das ist nicht erwünscht. Wie sage ich in der ~/.muttrc , er solle sich nur
verschlüsselt verbinden.

Andererseits müsste er das nicht eh, weil Google sicher keine
unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann selbst
ein Fehler? Man findet auch wenig darüber im Web.
-- 
Andreas
You know you are a redneck if
you've ever been involved in a custody fight over a huntin' dog.

[toc] | [next] | [standalone]


#232

FromHelmut Springer <delta+usenet@lug-s.org>
Date2017-04-11 19:33 +0000
Message-ID<0Tddlv5mI2a7Nv8@delta.citecs.de>
In reply to#231
Andreas Kohlbach <ank@spamfence.net> wrote:
> Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert

Das ist imaps, also eine per SSL/TLS gesicherte Verbindung.

> das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz
> 
> | Authentification (Plain)

Das ist die Authentication gegenueber dem IMAP Server (SASL Plain),
das hat mit der Verbindung nichts zu tun sondern geschieht ueber die
etablierte Verbindung.

 
> Das ist nicht erwünscht.

Bist Du sicher, dass Du das nicht willst?


> Wie sage ich in der ~/.muttrc , er solle sich nur verschlüsselt
> verbinden.

Du vermischt "Verbindung" und "IMAP Authentication", die hier
unabhaengig voneinander sind.


> Andererseits müsste er das nicht eh, weil Google sicher keine
> unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann
> selbst ein Fehler? Man findet auch wenig darüber im Web.

Man konnte die manpage lesen, muttrc.5 beinhaltet

       imap_authenticators
              Type: string
              Default: ??????

              This  is  a  colon-delimited list of authentication
              methods mutt may attempt to use to log in to an IMAP
              server,  in the  order mutt should try them.
              Authentication methods are either ???login??? or the right
              side of an IMAP ???AUTH=xxx??? capability string, e.g.
              ???digest-md5???, ???gssapi??? or ???cram-md5???. This option is
              case-insen??? sitive. If it's unset (the default) mutt
              will try all available methods, in order from
              most-secure to least-secure.

              Example:

              set imap_authenticators=???gssapi:cram-md5:login???

              Note:  Mutt  will only fall back to other
              authentication methods if the previous methods are
              unavailable. If a method is  avail??? able but
              authentication fails, mutt will not connect to the
              IMAP server.


-- 
Best Regards
helmut springer                                           panta rhei

[toc] | [prev] | [next] | [standalone]


#233

FromAndreas Kohlbach <ank@spamfence.net>
Date2017-04-12 17:17 -0400
Message-ID<87efwx2um8.fsf@usenet.ankman.de>
In reply to#232
On 11 Apr 2017 19:33:18 GMT, Helmut Springer wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> Wenn mutt sich mit imaps://imap.gmail.com/ hier verbindet, funktioniert
>
> Das ist imaps, also eine per SSL/TLS gesicherte Verbindung.
>
>> das zwar. Wenn ich beim Einloggen aber genau hinschaue, sehe ich kurz
>> 
>> | Authentification (Plain)
>
> Das ist die Authentication gegenueber dem IMAP Server (SASL Plain),
> das hat mit der Verbindung nichts zu tun sondern geschieht ueber die
> etablierte Verbindung.

Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"?
Würde okay sein.

>> Das ist nicht erwünscht.
>
> Bist Du sicher, dass Du das nicht willst?

Eine nicht verschlüsselte Verhandlungsphase will ich nicht.

>> Wie sage ich in der ~/.muttrc , er solle sich nur verschlüsselt
>> verbinden.
>
> Du vermischt "Verbindung" und "IMAP Authentication", die hier
> unabhaengig voneinander sind.
>
>
>> Andererseits müsste er das nicht eh, weil Google sicher keine
>> unverschlüsselte Autorisation erlaubt, und diese Meldung wäre dann
>> selbst ein Fehler? Man findet auch wenig darüber im Web.
>
> Man konnte die manpage lesen, muttrc.5 beinhaltet
>
>        imap_authenticators
> [...]

Brauche ich dann also nicht, da die Daten wegen meiner Fehlinterpretation
sicher sind.

Danke.
-- 
Andreas
You know you are a redneck if
you've ever hitchhiked naked,

[toc] | [prev] | [next] | [standalone]


#234

Fromdseppi@a1.net (David Seppi)
Date2017-04-13 10:23 +0000
Message-ID<2017-04-13$10.21.02@tin.seppi.name>
In reply to#233
Andreas Kohlbach schrieb:

> Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"?
> Würde okay sein.

Exakt. Hat den Vorteil, daß das Paßwort am Server nicht gespeichert
werden muß. Ein Hash reicht. (Das geht zwar bei ein paar verschlüsselten
Übermittlungen auch, aber dann muß der Hash auf dieses Verfahren
abgestimmt sein. Das erspart man sich hier, da eh der Transport
verschlüsselt ist.)

-- 
David Seppi
1220 Wien

[toc] | [prev] | [next] | [standalone]


#235

FromThomas Hochstein <thh@inter.net>
Date2017-04-14 11:36 +0200
Message-ID<dcsm.1704141136.243@meneldor.ancalagon.de>
In reply to#233
Andreas Kohlbach schrieb:

> Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"?

Ja.

Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im
Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig,
weil die Verbindung ja bereits gesichert ist, und hätte (b) den
Nachteil, dass das Passwort dann auf der Serverseite zwingend
unverschlüsselt gespeichert sein muss.

[toc] | [prev] | [next] | [standalone]


#236

Fromdseppi@a1.net (David Seppi)
Date2017-04-14 13:43 +0000
Message-ID<2017-04-14$13.37.36@tin.seppi.name>
In reply to#235
Thomas Hochstein schrieb:

> Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im
> Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig,
> weil die Verbindung ja bereits gesichert ist, und hätte (b) den
> Nachteil, dass das Passwort dann auf der Serverseite zwingend
> unverschlüsselt gespeichert sein muss.

Nicht zwingend. Es gibt Authentifizierungsmethoden, bei denen zwar das
Paßwort verschlüsselt übertragen wird, der Server abee trotzdem nur
einen (auf das Authentifizierungsverfahren angepaßten) Hash
speichern muß. Das ist dann allerdings unflexibel, da nur die zum
Hashverfahren passende Methode angeboten werden kann, die u.U. von
einigen Clients nicht unterstützt wird.

-- 
David Seppi
1220 Wien

[toc] | [prev] | [next] | [standalone]


#237

FromAndreas Kohlbach <ank@spamfence.net>
Date2017-04-14 15:58 -0400
Message-ID<87zifiwykn.fsf@usenet.ankman.de>
In reply to#235
On Fri, 14 Apr 2017 11:36:19 +0200, Thomas Hochstein wrote:
>
> Andreas Kohlbach schrieb:
>
>> Also Klardaten über eine sonst verschlüsselte Verbindung "getunnelt"?
>
> Ja.
>
> Eine "verschlüsselte" Anmeldung, bei der das Passwort nicht im
> Klartext ausgetauscht wird, sondern nur ein Hash, wäre (a) unnötig,
> weil die Verbindung ja bereits gesichert ist, und hätte (b) den
> Nachteil, dass das Passwort dann auf der Serverseite zwingend
> unverschlüsselt gespeichert sein muss.

:-)

Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung
unterdrücken, um Verwirrung zu vermeiden. Die Meldung bringt keinen
wirklichen Nutzwert.
-- 
Andreas
You know you are a redneck if
your mother has been involved in a fistfight at a high school sport event.

[toc] | [prev] | [next] | [standalone]


#238

FromHelmut Springer <delta+usenet@lug-s.org>
Date2017-04-14 20:54 +0000
Message-ID<0Tddu1cjIs8tNv8@delta.citecs.de>
In reply to#237
Andreas Kohlbach <ank@spamfence.net> wrote:
> Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung
> unterdrücken, um Verwirrung zu vermeiden.

Ich sehe da keinen Grund fuer Verwirrung.  Letztlich kann alles
verwirren, wenn man sich nicht auskennt.  Das daraus folgende
Benutzerinerface ist idR maximal entmuendigend und entspricht nicht
unbedingt der mutt-Philosohpie.


> Die Meldung bringt keinen wirklichen Nutzwert.

Sie gibt die verwendete Authentication bekannt, und dass das
password als solches an den server ging.   Es gibt Leute, die das
interessiert, koennte uebrigens von libsasl kommen  *shrug*

-- 
Best Regards
helmut springer                                           panta rhei

[toc] | [prev] | [next] | [standalone]


#241

FromThomas Hochstein <thh@inter.net>
Date2017-04-29 14:42 +0200
Message-ID<dcsm.1704291442.253@meneldor.ancalagon.de>
In reply to#237
Andreas Kohlbach schrieb:

> Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung
> unterdrücken, um Verwirrung zu vermeiden.

Darüber kann man streiten. Ich neige zu der Auffassung, dass es
insgesamt vorzugswürdig ist, die verwendete Methode mitzuteilen, eine
möglicherweise entstehende Verwirrung hinzunehmen und bestenfalls noch
einen Wissenszuwachs beim Benutzer zu erreichen. ;)

> Die Meldung bringt keinen wirklichen Nutzwert.

Sie gibt die verwendete Authentifizierungs-Methode an. Die heißt eben
"plain" - was eine konkrete Methode bezeichnet und nicht "im Klartext
und unverschlüsselt" bedeutet. Diese Angabe halte ich für durchaus
wünschenswert.

-thh

[toc] | [prev] | [next] | [standalone]


#242

FromAndreas Kohlbach <ank@spamfence.net>
Date2017-04-29 11:41 -0400
Message-ID<87ziezw7aq.fsf@usenet.ankman.de>
In reply to#241
On Sat, 29 Apr 2017 14:42:53 +0200, Thomas Hochstein wrote:
>
> Andreas Kohlbach schrieb:
>
>> Wenn auch technisch korrekt, sollte mutt dann aber diese Meldung
>> unterdrücken, um Verwirrung zu vermeiden.
>
> Darüber kann man streiten. Ich neige zu der Auffassung, dass es
> insgesamt vorzugswürdig ist, die verwendete Methode mitzuteilen, eine
> möglicherweise entstehende Verwirrung hinzunehmen und bestenfalls noch
> einen Wissenszuwachs beim Benutzer zu erreichen. ;)

Ich bevorzuge, dass nur Meldungen zu kritischen Ereignissen kommen per
Default. Der User aber auch in der Lage sein sollte, den Verbose-Level
anpassen zu können, wünscht er mehr (oder weniger) Information.

>> Die Meldung bringt keinen wirklichen Nutzwert.
>
> Sie gibt die verwendete Authentifizierungs-Methode an. Die heißt eben
> "plain" - was eine konkrete Methode bezeichnet und nicht "im Klartext
> und unverschlüsselt" bedeutet. Diese Angabe halte ich für durchaus
> wünschenswert.

Das wird normale Vorgehensweise, nicht nur bei mutt, sein. Daher IMO
überflüssig, es zu erwähnen. Wenn aber mal eine "nicht normale" Methode
genommen würde, hielt ich es schon wünschenswert, sie zu erwähnen.

Andererseits machen auch andere Programme das. Ich hatte mal bei Firefox
besonders drauf geachtet, was der unten in der Statusleiste anzeigt. Der
erzählt auch zu viel. Wie dass er gerade eine Verbindung herstellen will
(Ach was?). Gut, dass man hier diese Leiste ausblenden kann.
-- 
Andreas
You know you are a redneck if
you've never paid for a haircut.

[toc] | [prev] | [standalone]


Back to top | Article view | de.comm.software.mailreader


csiph-web