POP3 password in plaintext?

POP3 password in plaintext?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

http://www.theguardian.com/technology/2014/sep/29/londoners-wi-fi-security-herod-clause

says that POP3 passwords are sometimes transmitted in plain text.

Is plaintext transmission of passwords inherent in POP3
or is it optional?

Is there something we can and should do
to encourage users to stop the plaintext transmission of their
POP3 passwords?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

POP3 password in plaintext?

[Stephen J. Turnbull]

Richard Stallman writes:

 > [A source] says that POP3 passwords are sometimes transmitted in
 > plain text.
 > 
 > Is plaintext transmission of passwords inherent in POP3
 > or is it optional?

It's inherent.  There are other related protocols which purport to
give more security, but AFAIK they're all susceptible to man in the
middle attacks[1], which is why they haven't superseded POP3.

 > Is there something we can and should do to encourage users to stop
 > the plaintext transmission of their POP3 passwords?

There's not much users can do.

In most cases their mailboxes are on heavily defended, trusted systems
(from the users' point of view, I know you worry about the reliability
of the administrators), so the normal approach to this problem is to
use TLS to protect the channel from snooping.  If a virus has
installed a keyboard snooper on your machine, it reads the password as
you type.  If the admins on the mail host want to read your mail, they
can do so -- they have root.

IMAP4 may be more secure by default, I forget the details about IMAP.
I suppose you could add a "nanny mode" to Emacs POP clients to tell
the users that they're using an insecure channel if they POP3 to port
110 instead of 995 (the latter is the IANA-registered port for POP3
over TLS).

For those who care, there's a overview of POP3 here:
http://tools.ietf.org/html/rfc1939#page-3

More options for authentication here:
http://tools.ietf.org/html/rfc1734

These are very old RFCs (RFC 1939 is dated May 1996).



Footnotes: 
[1]  Eg, APOP uses MD5 plus a plain-text session salt transmitted
in-band to encrypt the password, which is easily breakable offline
with brute force attack for typical password lengths, and requires
that the server store the password for comparison of the hashes.

Re: POP3 password in plaintext?

[Ted Zlatanov]

On Tue, 30 Sep 2014 10:46:55 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> I suppose you could add a "nanny mode" to Emacs POP clients to tell
SJT> the users that they're using an insecure channel if they POP3 to port
SJT> 110 instead of 995 (the latter is the IANA-registered port for POP3
SJT> over TLS).

I can't think of a place to put it (maybe the modeline?), but an
indicator that 4 secure connections and 3 insecure connections are open
would certainly be nice.  The user can then judge the situations
themselves and even catch unexpected connections.

Ted

Re: POP3 password in plaintext?

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> http://www.theguardian.com/technology/2014/sep/29/londoners-wi-fi-security-herod-clause
>
> says that POP3 passwords are sometimes transmitted in plain text.
>
> Is plaintext transmission of passwords inherent in POP3
> or is it optional?

Modern pop3 servers support STARTTLS, and Emacs will upgrade to a TLS
connection whenever the server supports it.  (If you have an Emacs
compiled with gnutls support, but I would guess that almost all Emacs
instances has that.)

Virtually all the Emacs network transports that I know of will upgrade
to TLS opportunistically, if the servers allow it, so Emacs should send
no passwords unencrypted.

The only exceptions are HTTP and IRC, unless the latter has been fixed
lately.  And there are hopefully nobody who does a login that matters
over HTTP.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: POP3 password in plaintext?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    There's not much users can do.
    ...
    In most cases their mailboxes are on heavily defended, trusted systems
    (from the users' point of view, I know you worry about the reliability
    of the administrators), so the normal approach to this problem is to
    use TLS to protect the channel from snooping.

These points seem to conflict.  First, there is no protection.
Second, there is protection: use TLS for this communication.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: POP3 password in plaintext?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Modern pop3 servers support STARTTLS, and Emacs will upgrade to a TLS
    connection whenever the server supports it.  (If you have an Emacs
    compiled with gnutls support, but I would guess that almost all Emacs
    instances has that.)

That is good.

Would it make sense to warn if a POP server does not support STARTTLS?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: POP3 password in plaintext?

[Stephen J. Turnbull]

Richard Stallman writes:

 > These points seem to conflict.  First, there is no protection.
 > Second, there is protection: use TLS for this communication.

Not at all.  If the server provides TLS, there is protection, and both
modern servers and Emacs (at least Gnus and probably RMail according
to larsi, but I don't think VM does) are able to use STARTTLS to
convert an unencrypted channel to an encrypted one, *before* the
password is sent.

But even today not all servers provide TLS, and of those that do, some
accept unencrypted connections but don't use STARTTLS.  The user can
do nothing about that; it requires reconfiguration and possibly
upgrading software on the server.  All Emacs can do is warn the user.

I liked Ted's suggestion about providing modeline indicators.
However, a lot of HCI research shows that users don't notice such
indicators and often misinterpret them.  While Emacs users are
generally more aware of such indicators and of their correct
interpretation, I think something like the "novice" feature to provide
an easily disabled "in your face" warning about unencrypted channels
should be considered.

It's not clear to me that there's a good way to do it.  Perhaps having
the `password-read' function (and any other functions that are used to
read passwords) check for unencrypted connections and warn the user
would work.

Regards,

Re: POP3 password in plaintext?

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>
>  > These points seem to conflict.  First, there is no protection.
>  > Second, there is protection: use TLS for this communication.
>
> Not at all.  If the server provides TLS, there is protection, and both
> modern servers and Emacs (at least Gnus and probably RMail according
> to larsi, but I don't think VM does) are able to use STARTTLS to
> convert an unencrypted channel to an encrypted one, *before* the
> password is sent.

Transparent STARTTLS on demand would seem useless against
man-in-the-middle attacks.  It's just good against eavesdropping on
unintercepted traffic.  And you don't even need to be true
man-in-the-middle: you just need to be faster answering the STARTTLS
negotiation.

-- 
David Kastrup

Re: POP3 password in plaintext?

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On 9/30/14 9:00 PM, Stephen J. Turnbull wrote:

> I liked Ted's suggestion about providing modeline indicators.
> However, a lot of HCI research shows that users don't notice such
> indicators and often misinterpret them.  While Emacs users are
> generally more aware of such indicators and of their correct
> interpretation, I think something like the "novice" feature to provide
> an easily disabled "in your face" warning about unencrypted channels
> should be considered.

Modern POP/IMAP clients tend to have a checkbox or a setting to require
SSL/TLS when connecting. If the protocol doesn't start TLS (and isn't
connected to an SSL port) then it is considered a connection error. This
setting is configured up-front, at the same time that the user
configures the server name and port. In this day and age it might make
sense to have such a checkbox default to "on".

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: POP3 password in plaintext?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Transparent STARTTLS on demand would seem useless against
    man-in-the-middle attacks.  It's just good against eavesdropping on
    unintercepted traffic.  And you don't even need to be true
    man-in-the-middle: you just need to be faster answering the STARTTLS
    negotiation.

Are other protocols for fetching mail better
in security?

David Caldwell <david@porkrind.org> wrote:

    Modern POP/IMAP clients tend to have a checkbox or a setting to require
    SSL/TLS when connecting. If the protocol doesn't start TLS (and isn't
    connected to an SSL port) then it is considered a connection error. This
    setting is configured up-front, at the same time that the user
    configures the server name and port. In this day and age it might make
    sense to have such a checkbox default to "on".

That makes sense -- if STARTTLS in POP3 is fundamentally adequate.
But if Kastrup is right, that isn't so.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: POP3 password in plaintext?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     Transparent STARTTLS on demand would seem useless against
>     man-in-the-middle attacks.  It's just good against eavesdropping on
>     unintercepted traffic.  And you don't even need to be true
>     man-in-the-middle: you just need to be faster answering the STARTTLS
>     negotiation.
>
> Are other protocols for fetching mail better
> in security?
>
> David Caldwell <david@porkrind.org> wrote:
>
>     Modern POP/IMAP clients tend to have a checkbox or a setting to require
>     SSL/TLS when connecting. If the protocol doesn't start TLS (and isn't
>     connected to an SSL port) then it is considered a connection error. This
>     setting is configured up-front, at the same time that the user
>     configures the server name and port. In this day and age it might make
>     sense to have such a checkbox default to "on".
>
> That makes sense -- if STARTTLS in POP3 is fundamentally adequate.
> But if Kastrup is right, that isn't so.

My bet is on Kastrup not being right.  But I'd be interested to know
why.

-- 
David Kastrup

Re: POP3 password in plaintext?

[Ted Zlatanov]

On Wed, 01 Oct 2014 13:00:56 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> It's not clear to me that there's a good way to do it.  Perhaps having
SJT> the `password-read' function (and any other functions that are used to
SJT> read passwords) check for unencrypted connections and warn the user
SJT> would work.

I think you mean `open-network-stream'?

On Tue, 30 Sep 2014 22:42:50 -0700 David Caldwell <david@porkrind.org> wrote: 

DC> Modern POP/IMAP clients tend to have a checkbox or a setting to require
DC> SSL/TLS when connecting. If the protocol doesn't start TLS (and isn't
DC> connected to an SSL port) then it is considered a connection error. This
DC> setting is configured up-front, at the same time that the user
DC> configures the server name and port. In this day and age it might make
DC> sense to have such a checkbox default to "on".

I agree for most protocols, now that almost all our platforms support
GnuTLS. I think it would also help to have a certificate manager UI,
especially for self-signed certificates. I'd like to work on it after
the impending release.

Ted

Re: POP3 password in plaintext?

[Stefan Monnier]

> I liked Ted's suggestion about providing modeline indicators.

I'd much rather just signal an error if a password is sent in the clear.
And then provide some configuration option to indicate when it's OK to
send the password in the clear on this connection.


        Stefan

Re: POP3 password in plaintext?

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I liked Ted's suggestion about providing modeline indicators.
>
> I'd much rather just signal an error if a password is sent in the clear.
> And then provide some configuration option to indicate when it's OK to
> send the password in the clear on this connection.

Yes, sort of.

What I had planned on implementing was a way to make the user manage the
security more explicitly.  Here are the main options we need:

1) The connection is TLS, and the certificate is valid.  Everything OK;
don't ask the user for anything.

2) The connection is TLS, but the certificate can't be validated (i.e.,
self-signed certificate, which is very common on pop3/imap/smtp/nntp/etcp
connections), or it is invalid.

We then notify the user of this, display bits of the certificate, and
ask how to proceed.  The user will typically say "no, get me out of
here", "OK for this session only" or "OK always".  Emacs will then store
the choice, and store a fingerprint of the certificate, so that we can
verify that we're still making the same choice later on.

3) The connection is not TLS: Ask the user whether she really wants to
send anything unencrypted to this server, and store the choice.


It can all be done on the `open-network-stream' level. 

Somebody just has to write this thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: POP3 password in plaintext?

[Stefan Monnier]

> What I had planned on implementing was a way to make the user manage the
> security more explicitly.  Here are the main options we need:

Sounds nice.

> Somebody just has to write this thing.

What are you waiting for?


        Stefan

Re: POP3 password in plaintext?

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On 9/30/14 10:33 PM, David Kastrup wrote:
> Transparent STARTTLS on demand would seem useless against
> man-in-the-middle attacks.  It's just good against eavesdropping on
> unintercepted traffic.  And you don't even need to be true
> man-in-the-middle: you just need to be faster answering the STARTTLS
> negotiation.

The CA system[1] prevents MITM attacks. The best an attacker could do is
maybe stop the encryption from starting in the first place, but in my
book that should be an error.

-David


[1] https://en.wikipedia.org/wiki/Certificate_authority


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: POP3 password in plaintext?

[Ted Zlatanov]

On Wed, 01 Oct 2014 16:02:12 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> What I had planned on implementing was a way to make the user manage the
LMI> security more explicitly.  Here are the main options we need:
...
LMI> It can all be done on the `open-network-stream' level. 

We discussed this before in several bug discussions. The GnuTLS errors
(from an invalid certificate, for instance) happen at the C level and
there are problems with trying to be interactive while reading from a
network stream. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11267,
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15057,
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9017,
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16784, and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16978

IIRC, the agreed-upon direction in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16978 was that we said the
certificate UI was going to help the user manage certificate. And the
errors from GnuTLS would point the user to that UI and tell them how to
remedy the problem.  And there would be magic dust and happy unicorns.

Ted

Re: POP3 password in plaintext?

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Wed, 01 Oct 2014 13:00:56 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
 > 
 > SJT> It's not clear to me that there's a good way to do it.  Perhaps having
 > SJT> the `password-read' function (and any other functions that are used to
 > SJT> read passwords) check for unencrypted connections and warn the user
 > SJT> would work.
 > 
 > I think you mean `open-network-stream'?

No, I really do mean "password-read".  Mostly because not all
protocols demand authentication immediately on opening a stream.  Eg,
many sites can be accessed with HTTP, will switch to HTTPS without
authentication of the client, then present an HTML document for
login.

 > DC> configures the server name and port. In this day and age it might make
 > DC> sense to have such a [use TLS or fail] checkbox default to "on".
 > 
 > I agree for most protocols, now that almost all our platforms support

+1

 > GnuTLS. I think it would also help to have a certificate manager UI,
 > especially for self-signed certificates. I'd like to work on it after
 > the impending release.

I think the self-signed cert manager should default to one-time-only
or a short local expiration (1 hour? 1 day?) even if the cert is
long-lived.  Self-signature means that the server doesn't care to
devote much financial resources to security (which may be correlated
with carelessness concerning other security resources), and it's quite
possible that some of those will be evil sites, recognized as such by
user intuition, and I'd prefer to be warned about them on a second
approach.

Re: POP3 password in plaintext?

[Ted Zlatanov]

On Thu, 02 Oct 2014 10:58:10 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> I think you mean `open-network-stream'?

SJT> No, I really do mean "password-read".  Mostly because not all
SJT> protocols demand authentication immediately on opening a stream.  Eg,
SJT> many sites can be accessed with HTTP, will switch to HTTPS without
SJT> authentication of the client, then present an HTML document for
SJT> login.

Clearly that's not possible, because the read password can be used at
any point by the Lisp code; it's just data from that point on. Do you
mean we should be able to send a password directly to a network or
process stream at the C level? That makes a lot of sense to me and
connects to the idea of "secret" data in the Emacs core.

SJT> I think the self-signed cert manager should default to one-time-only
SJT> or a short local expiration (1 hour? 1 day?) even if the cert is
SJT> long-lived.  Self-signature means that the server doesn't care to
SJT> devote much financial resources to security (which may be correlated
SJT> with carelessness concerning other security resources), and it's quite
SJT> possible that some of those will be evil sites, recognized as such by
SJT> user intuition, and I'd prefer to be warned about them on a second
SJT> approach.

That should be a user choice so yes it sounds reasonable, but no I don't
think it should be the default.

Ted

Re: POP3 password in plaintext?

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > SJT> No, I really do mean "password-read".  Mostly because not all
 > SJT> protocols demand authentication immediately on opening a stream.  Eg,
 > SJT> many sites can be accessed with HTTP, will switch to HTTPS without
 > SJT> authentication of the client, then present an HTML document for
 > SJT> login.
 > 
 > Clearly that's not possible, because the read password can be used at
 > any point by the Lisp code; it's just data from that point on.

Sure, but most of the sites I access work that way.  The TLS
connection is basically anonymous, and authentication is done over
that connection.  If the site presents a certificate, then you can be
pretty sure it's the right site to give your credentials to, and the
site is happy because it doesn't give you anything but a login screen
until you do give it your credentials, at which point you know the
site and the site knows you and you can do your business together.

 > Do you mean we should be able to send a password directly to a
 > network or process stream at the C level? That makes a lot of sense
 > to me and connects to the idea of "secret" data in the Emacs core.

No, I don't mean anything like that.  That may be the right idea, but
I haven't thought carefully about it.  I'm just telling you that we
can't depend on sites demanding authentication during the connection
process.