From: Tomas K. <to...@us...> - 2008-01-06 12:34:42
|
Thijs Kinkhorst wrote: > > On Saturday 5 January 2008 08:24, Fredrik Jervfors wrote: >> > There is already a config setting that allows you to encrypt this >> > information ($encode_header_key; see conf.pl SMTP or Sendmail setting >> > details-->"Header encryption key"). I think it should remain in place. >> > If the config setting is only in DEVEL, then I think the >> > better thing to do is port it to STABLE. I do not support the >> wholesale >> > removal of this information. >> >> Since this is a configurable setting (by the system administrator), I too >> is in favour of keeping it. It should be up to the system owner to decide >> if he wants to include the IP address used by the OP in the headers or >> not >> (i.e. only have it in the logs). There are situations when having the IP >> in the headers is quite useful, so SquirrelMail should definitely keep >> the >> option to have it that way. > > I'm not fond of this for a couple of reasons: > 1) It is not a substitute for proper logging anyway. > 2) It's off by default, while I think we should only be broadcasting this > kind > of data when the administrator explicitly wants that. > The way it's implemented does not allow for an easy way to make us > turn it on by default since a unique key is needed in the config. > 3) We use a onetimepad function with a static key, so there's nothing > onetime > about it anymore making it quite easy to crack. The onetimepad function > is > useful for something like the cookie where we generate a new pad every > time. > Our own config tool says it: > print "Warning: used encryption function is not bulletproof. When > used\n"; > print "with static encryption keys, it provides only minimal > security\n"; > print "measures and information can be decoded quickly.\n"; > 4) The IP-address is used twice, also in the message ID for no reason. > The message ID has a much wider distribution than the Received header. > > I propose that we look at it the other way round. What problem do we want > to > solve? And then, which technology is the best way to solve it? > > Stated problem: > An adminstrator wants, in the case of abuse, to be able to determine > which > username took a malicious action, and from which IP this user did that. > > To solve this, we need to store somewhere who does what from which IP. We > can > store in one place at the server side, or we can put it in every email > sent. > > Advantages of putting it in every mail: > - Tracable by the receiver. > - Already works. > Disadvantages: > - Has a privacy concern. > - May not be available to the server administrator, depends on third party > to > get this info. > - Is not sufficient. A breakin where all of a user's emails are deleted > cannot > be solved by this method, so additional logging is required anyway. > Encoding may partially resolve this but needs to be implemented much > differently from how it is now. > > Advantages of storing it server-side: > - All needed information available to the server administrator. > - All needed information *only* available to the server administrator. > - For IP-address, already works (webserver logs). > Disadvantages: > - Needs some way to store username aswell. Available as a plugin. > > Concluding from these options, I see that the main drawback of the > serverside > storage is the need for an extra plugin to store the username, otherwise > it > seems superior to the broadcast method. > > One may reason that the username is in a number of cases already > publically > known. So it would already be an improvement to just remove the IP from > the > headers and depend on existing logging as a replacement for that. > > To completely solve this, it would be best if we included logging by > default. > For a serious email application, logging stuff does not seem like a bad > thing. We could "corelize" logging functionality with possible plugins to > handle different styles (syslog, textfile, sql). > Every standalone email client puts user's home IP in email headers. SMTP servers do that by default. In SquirrelMail "email client" is user's browser running on his or her machine. SquirrelMail scripts are only processing actions executed on user's machine. $encode_header_key encrypts username, remote address, proxy address AND message id. Logging facilities depend on OS and require additional setup steps. You want to increase user's privacy by violating security of webmail admins position. Good admins will have custom loggers, but beginners won't have them and their setups can be abused. This code you are talking about has reference to closed SquirrelMail bug tracker with thoughts about it. Other related bug tracker is mentioned on first tracker. Don't confuse privacy with security. By removing IP you are not increasing user's security. If user's account is hijacked, user won't be able to prove that he or she is not the one that send bad emails. Every twoway crypto can be cracked. You are free to use stronger crypto, but X-Squirrel-UserHash header will provide cribs usable for cracking even stronger crypto. -- Tomas -- View this message in context: http://www.nabble.com/Re%3A--SM-CVS--SF.net-SVN%3A-squirrelmail%3A--12840--branches-SM-1_4-STABLE-squirrelmail-class--deliver-Deliver.class.php-tp14620259p14647778.html Sent from the squirrelmail-devel mailing list archive at Nabble.com. |