Alessandro Vesely wrote:
> On Fri 27/Feb/2015 15:26:03 +0100 Jan Ingvoldstad wrote:
> > On Fri, Feb 27, 2015 at 12:05 PM, Alessandro Vesely <[email protected]> wrote:
> >>
> >> but would it be worth?
> >>
> > Use case 1:
> >
> > Hi, this is $customer,
> >
> > could you please provide a log for which IP addresses have tried to logon
> > as $user?
>
> The complete list of IP addresses would do. You cannot tell whether the
> password, the userid, or both were wrong. IME, intrusion attempts --where
> both
> tokens are being guessed-- are somewhat more frequent than honest mistyping,
> but discerning which is which is not always obvious, and needs human judgment.
You don't want to disclose the list of customers who mistyped their
password that day.
However, disclosing to $user the list of ips that tried to log into that
account, is no problem. If techy enough, he could then evaluate if it's
a FP or something to worry about.
You could also provide them as part of the normal interface, like ssh
("Last login: ") or gmail do.
> Afterwards, I realized that's not needed yet, albeit userid-guessing has
> slightly improved. For SMTP, stolen passwords get deployed with no prior
> failed login attempts.
At this point seeing that this customer that has always connected from
US now suddenly appears with a Chinese IP should be a big red flag.
Maybe he is using Tor and switching countries every 5 minutes (and
should thus deactivate such option for his account), or decided to use a
Chinese proxy for some need... or more likely a Chinese proxy is being
used by an attacker.
For a long time banks have been taking these data into account, and
approving a charge from a different continent shortly after operating
locally, would be considered a negligence.
Email is a quite different business, but if properly implemented, and
there's an adequate override procedure (from phoning support to
additionally providing their maiden name), it's a nice security feature.
> > Use case 3:
> >
> > Dear $abusedept,
> >
> > your IP address $IP has been involved in multiple login attempts to
> > numerous IMAP accounts, and we have therefore been forced to block access
> > from it.
>
> Just block them. ISP's abuse teams don't even reply, except for automated
> stuff. They're usually unable to contact their users, and do nothing even
> with
> zombie reports.
There are big differences amongst companies. Some will take it
seriously, and disconnect/filter the compromised machines, others will
perhaps rely to the customer (who may do any of these), and there are
those that don't even read the abuse mailbox.
Also note that even though some abuse teams don't reply, they may have
actually handled it.
> Typically, you cannot identify people by the IP addresses they use, except if
> they have to use fixed IPs. In that case, auto-blocking after 3 failed
> attempts forces them to call and explain.
>
> Ale
That you cannot identify them, doesn't mean they can't.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
