Auteur: W B Hacker Date: À: Exim Users Sujet: Re: [exim] 419 spammer - Help with AUTH ACL
Edgar Lovecraft wrote: > On Mon, 01 Jun 2009 23:01:41 +0800 W B Hacker wrote:
>
> ..<snip>...
>> It should not be as easy for an attack to suceed as you claim - your
>> authentication may have holes in it.
>>
>
> Bill,
>
> Just as a note, one of the "new" things that spammers have figured out
> is to use the account settings as defined in a computers email client;
> yes, everytime I have seen this happen the user has gotten one kind of
> malware or another on the system, normally things they have installed...
>
No doubt ... those of use who have never used WinWOEs 'networked' tend to forget
that.. but it is the rule rather than the exception for most user-bases.
Not here - we have zero Win users.. except for the odd Webmail use - see below.
> Most people (whether they should or not) save the password so that they
> never have to type it in. Any way, once they have the account settings,
> they just send that information to other computers they have, and start
> sending things.
>
> And yes, I have seen some accounts, normally webmail accounts, get brute
> forced, but only when the passwords have been 4 characters or less, or
> when a password has been set as varation of the username.
>
> ..<snip>...
>
There's the far larger danger - and not brute-forced, but captured...
Anyone who uses a Webmail client over a 'borrowed' or 'public' PC is odds-on
going to be using a WinBox, even if their 'primary' machine is not such. And
that means a *very* high probability of having a keystroke logger with remote
reporting capability.
Our long-term 'counter' to that risk had been separate UID:PWD for Webmail and
the ability to change it at the next login w/o affecting the 'principal' MUA
UID:PWD settings. An SMS, phone, or fax and we'll do that FOR the user as well,
and/or temporarily disable if alarms kick in on the server.
Going forward with a new Webmail client, we're looking at 'also' having the
Webmail user select from a randomly-positioned graphic - one among several -
with a mouse-click - as has been used by some of the financial services giants.
Pity some of those paid less rigourous attention to the rest of their 'core'
business (Countrywide).
The html has to use a call for the graphic that is essentially 'one time' coded,
whilst the back-end relates the choice - 'out of sight' - to the specific user
and no other. Fortunately, our back-end for auth is PostgreSQL, so the
flexibility is already there.
