Hi Brandon,
Just a quick note to be clear, the CID RFC Draft doesn't specify
especially the 'client identifier', and the MAC address is just an
example. In the real world of course, much better client identifiers
are available, and the CID proposal recognizes that and assumes that the
'device' implementations, would use the most accurate identifier available.
For instance, WebMail might use 'HTML Canvas' and 'Cookies', or an under
lying machine/device identifier accessible to a browser type. It
doesn't really matter which one is chosen, other than it should offer
some elements of uniqueness.
What is significant, is that the CID proposal also addresses how to only
present that over encrypted channels, while still leaving support for
legacy methods.
But it is up the server implementation on what controls and restrictions
they wish to place or allow, whether server wide, domain wide, or even
per user controls.
As you pointed out, some of the 'big boys' have invested considerable
amounts into creating 'auth' rules and mechanisms, however this is a
simple and easy way for all operators to gain extra levels of control.
For instance the WebMail only user can 'lock' down any attempts to use
the credentials, to only those who have the correct CID, whether that be
HTML Canvas, or Cookie.. and even better, alert the user to someone who
used their email address and password, from an environment where that
information wasn't presented.
And given the bad habit of people using the same credentials (email and
password) for multiple services, the ability of bad bot operators to
perform dictionary and brute force attempts, (as per the original
reporter) we see this as an important ability.
As well, it offers the additional ability to report such attacks as
described, so that the server can detect and prevent such future
attacks, without solely locking out the originating IP Address.
PS, as much as this method can also be used to measure cases where a
'device' identifier magically transports itself to different GEO
locations, my phone today alone reported that I was in Montreal,
Vancouver, Edmonton, Las Vegas, and New York.
IPv6, portable dynamic networks, and many other 'flex routing' issues
effectively make that difficult, aside from some large scale (eg China
vs US geo locations), but this goes beyond that, I want to know if
someone in the same coffee shop is trying to use my credentials.
But it will take work making this a standard of course, but in the
interim, value can be seen even in the mosts limited server
deployments. As long as email operators wish to continue supporting
IMAP/POP/SMTP we need to improve those protocols to some level, where we
can 'who' or at least 'what' is trying to use a person's security
tokens, in this case the email address and password.
And hopefully, those who use this can detect those 'slow botnet IMAP
scans' on their first attempt, no matter what distributed methods are
used to attempt such attacks.
On 17-10-06 03:18 PM, Brandon Long wrote:
We didn't release any, since we changed focus. The simple answer is,
instead of PLAIN which has a sasl format of (taking the abnf from RFC
4616):
message = [authzid] UTF8NUL authcid UTF8NUL passwd
it includes a client-token:
message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token
I also wouldn't recommend using the MAC address as in Michael's
proposal, as that as privacy implications. It should either use a
device specific API to request a unique id and store it in the client,
or just have the client create one and keep it. The point is, that
always a user to wipe a device and give it to someone else, or even
just wipe and replace, without being able to track the user in other ways.
The benefits are the same, if you've never seen a client-token before,
you need to be more careful with it, but if you have seen it before,
then it's less likely that the login attempt is a hijacking or
dictionary attack.
It can also aid in using say geohop stats. Ie, one easy way to try to
detect hijacking is to geoloc the accessing IP, and see how close it
was to the last access, or keep track of where the user is accessing
from. This has obvious issues if your users travel. If a user with a
phone that supports it goes somewhere else, chances are they'll access
from the phone first, even if their desktop client doesn't support
client-token, so you have a strong signal that they traveled somewhere
else.
All of this requires per-user login permission systems, nothing as
simple as say banning AWS or China, its' knowing whether a given user
ever uses your service from those locations. A first access from that
location may be blocked, requiring the user to go to a web page and
verify the access attempt (web access gives you a lot more signals, so
doing login permission detection there is often easier).
Anyways, the massive service providers have been having to do this
stuff for almost a decade, it's always been a matter of time til it
filters down to the larger or medium size providers.
Anyways, that's the reason we moved to requiring OAUTH by default, and
requiring users to jump through hoops to enable "less secure apps"
(ie, password based auth).
Brandon
On Fri, Oct 6, 2017 at 11:57 AM, <[email protected]
<mailto:[email protected]>> wrote:
Is there any documentation available about PLAIN-CLIENTTOKEN? All
I can find are SMTP transcripts about connecting to Gmail.
Best regards,
Andris Reinman
On 6 Oct 2017, at 21:24, Brandon Long via mailop
<[email protected] <mailto:[email protected]>> wrote:
I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead,
since you can then use it for imap/pop/smtp simply.
Or focus on oauth...
On Oct 6, 2017 7:57 AM, "Michael Peddemors"
<[email protected] <mailto:[email protected]>> wrote:
SMTP Auth Scanners are easier to stop, which is why there are
more IMAP scanners being seen in the wild.
But that is why we are pushing forward on our CID
implementations..
https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/
<https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/>
Can't really block AUTH attempts strictly by 'firewall' or IP
rules, as a bot could be operating out of shared or dynamic
space, which would mean that you effectively block legitimate
users from accessing email.
We actually have a RATS-AUTH list designed to report on IP(s)
used for AUTH attacks, the broken bots are easier to pick up.
But this isn't a 'Chinese' thing only, we see lot's of these
attacks coming from everywhere, including Amazon AWS etc..
On 17-10-06 05:30 AM, Tim Bray wrote:
On 06/10/17 10:51, Otto J. Makela wrote:
Are you keeping an eye out for (mostly Chinese)
botnets doing slow IMAP scans,
using scraped email addresses and apparently going
through whole dictionaries?
I haven't seen them. But we are getting a lot more SMTP
auth scanners
than we used to.
We just drop them in the firewall for a bit. We've
dropped about 300
IPv4 addresses in the last 6 hours.
Tim
_______________________________________________
mailop mailing list
[email protected] <mailto:[email protected]>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
<https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower
TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 <tel:604-682-0300> Beautiful British Columbia,
Canada
This email and any electronic data contained are confidential
and intended
solely for the use of the individual or entity to which they
are addressed.
Please note that any views or opinions presented in this
email are solely
those of the author and are not intended to represent those
of the company.
_______________________________________________
mailop mailing list
[email protected] <mailto:[email protected]>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
<https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
_______________________________________________
mailop mailing list
[email protected] <mailto:[email protected]>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
<https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
