[Dovecot] Detail improvement: %c variable

Hadmut Danisch hadmut at danisch.de
Mon Feb 24 15:19:31 UTC 2014


On Mon, Feb 24, 2014 at 12:54:51AM +0100, Reindl Harald wrote:
>
> you described nothing relevant


You're quite ignorant and obviously don't understand the background. 




> you only talk why 127.0.0.1 is treated as "secured"
> well because it is by definition, if you don't trust
> 127.0.0.1 you have lost the game at all


Which is wrong. 

I did not say that I did not trust 127.0.0.1. I said that I do not
trust the Web-IMAP-Gateway (such as squirrelmail) if the client uses
an untrusted computer. 





> 
> >> how do you imagine a man-in-the-middle-attack on 127.0.0.1
> > 
> > You're confusing the different attacks. This has nothing to do with a
> > man-in-the-middle. This is against a passive eavesdropper,
> > e.g. someone watching people entering the password at a web interface,
> > or a keylogger on an unreliable computer
> 
> RTFM - these is *logging* and there it does not make a difference
> in case of security if it was a encrypted connection or one
> from LOCALHOST where there is no wire at all between client and
> server


Again, your statements are technically wrong and you obviously do not
understand the security implications. 


As I said before, the Webserver protects the Web access with a
one-time-password. So an IMAP password caught at a computer using the
Web interface is useless for an attacker, since the attacker could not
login again with caught passwords. 

But the attacker could use the password fetched by a keylogger to
directly access the IMAPS port (without the web and thus without the need
to use a one-time-password) if the web interface (going over
127.0.0.1) and IMAPS share the same password - what they do due to bad
design of dovecot. 


May I kindly ask you to stop giving negativ or even harsh and
offensive replies as long as you do not understand the security
implications and the web technology?

Your statements about man-in-the-middle and trusting 127.0.0.1 are so
technically wrong, that I do not see a point in this conversation. 


As far as I can see dovecot does not consider 127.0.0.1 as "secured"
for any good reason, just to make debugging in plaintext easier. This
is a severe security gap. 


Hadmut


More information about the dovecot mailing list