51 lines
2.2 KiB
Plaintext
51 lines
2.2 KiB
Plaintext
MBOX-Line: From guenther+imap at sendmail.com Wed Nov 2 20:49:49 2005
|
|
To: imap-protocol@u.washington.edu
|
|
From: Philip Guenther <guenther+imap@sendmail.com>
|
|
Date: Fri Jun 8 12:34:36 2018
|
|
Subject: [Imap-protocol] username/password
|
|
In-Reply-To: <43699192.2040701@fastmail.co.uk>
|
|
References: <436988D9.8040106@fastmail.co.uk>
|
|
<Pine.OSX.4.64.0511022009390.533@pangtzu.panda.com>
|
|
<43699192.2040701@fastmail.co.uk>
|
|
Message-ID: <200511030449.jA34nnMn087966@lab.smi.sendmail.com>
|
|
|
|
Max Waterman <davidmaxwaterman@fastmail.co.uk> writes:
|
|
>It seems that the options are :
|
|
>
|
|
>1) propose a new RFC to split the username/password, which can then be
|
|
>implemented
|
|
|
|
Given the rabid desire of many client implementors to minimize the
|
|
number of round-trips required by IMAP, my guess is that such a
|
|
proposal would be a virtual non-starter, especially given that
|
|
support for STARTTLS is now mandatory. That is, there already is
|
|
a standardized method of eliminating the problem: require use of
|
|
STARTTLS or an authentication mechanism that's safe from passive
|
|
attacks, so why come up with a workaround for this problem when it
|
|
would just delay support for the mandated methods?
|
|
|
|
I will note that no direct protocol change is required for what you
|
|
want: clients would merely need to use a (synchronizing) literal
|
|
for the password argument to the LOGIN command, while server
|
|
implementors would need to trigger any "is this user permitted to
|
|
use cleartext logins" check immediately after the username is
|
|
received and condition whether to send a tagged NO or a continuation
|
|
response on that check. For some servers, moving the check there
|
|
may be trivial, and perhaps should be encouraged, but the ease
|
|
depends on the design of the server. A security analysis of the
|
|
effects of moving the check there would be in order as well.
|
|
|
|
|
|
>2) use a separate servers for secure and insecure users (I suppose a
|
|
>second NIC would suffice?)
|
|
|
|
If you must support insecure logins, then restricting them to a
|
|
separate IP or port may be the most easily deployed way to prevent
|
|
accidental leaking of passwords. It's certainly something you can
|
|
do now without waiting for client and servers implementations to
|
|
change.
|
|
|
|
|
|
Philip Guenther
|
|
|