Hey, that's awesome, thanks for the PLAIN-CLIENTTOKEN description! I was finally able to add basic support to my own mail server (can be tested at https://ethereal.email):
$ openssl s_client -crlf -connect imap.ethereal.email:993 * OK Ethereal Email IMAP Server ready A CAPABILITY * CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN ENABLE ID SASL-IR A OK CAPABILITY completed A AUTHENTICATE PLAIN-CLIENTTOKEN "AHo0YzJkbWcycWU2ZGdid2hAZXRoZXJlYWwuZW1haWwAQXJqZVVBNWsyd1lqWWo0eWJKAHRlc3Q=" A OK z4c2dmg2qe6dgbwh@ethereal.email authenticated I didn't manage to get any real mail clients to pick this authentication scheme though, all the clients I tested went with the regular "AUTHENTICATE PLAIN". Regards, Andris 2017-10-07 1:18 GMT+03:00 Brandon Long <bl...@google.com>: > 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, <andris.rein...@gmail.com> 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 <mailop@mailop.org> >> 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" <mich...@linuxmagic.com> >> 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/ >> >> 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 >>> mailop@mailop.org >>> 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 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 >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
