undefined | Better HN

0 pointscallahad9y ago0 comments

I'm not sure it's a fundamental flaw: it's exactly identical to sending a confirmation email when a user signs up for a website, which is considered a best practice on the Web. If that works well enough for the Web at large, it should work here, too.

As far as I can tell, the trick is building up that initial reputation and doing as much mitigation as possible up front: checking for MX records, rate limiting, soft-failing with CAPTCHAs for things that look suspicious, etc.

I know what I'll be hacking on for the rest of the week. :)

0 comments

danieltillett9y ago

I should have phrased this differently - it is the fundamental flaw of all email based authentication systems. Your approach is currently a bit more prone to problems since you are one nasty script away from being bounced out of existence.

Yes you need to protect the log in page by rate limiting, Captcha, looking up mx records, etc.

One approach I have thought would be good to use is a rainbow table like approach. Most people are not very imaginative about the fake email accounts they use.

jcrites9y ago

One workaround might be to request that the user send an initial email to your servers from their address before attempting the authentication. You'd want to validate that the email arrived and is valid according to SPF/DKIM/DMARC. You might consider allowing only messages that are positively authenticated by one of those technologies (not e.g. vacuously valid for lack of SPF records). Admittedly this will require a more complex user interaction, but it will avoid the abuse problem you're describing. You could make sending this email easy by supplying an appropriately filled out mailto: link; it should be enough to click it and send. You'd then follow this up with your current authentication step.

I've been thinking about this space for a while (e.g. https://news.ycombinator.com/item?id=12411204 ) and would be happy to chat or brainstorm.

j / k navigate · click thread line to collapse