Rate limiting (Part 🌍 of 2)

Announcements Releases
1

This isn’t a particularly exciting change, but one I feel is important to do as Shmeppy moves out of earliest access…

There are a lot of different kinds of cyber attacks out here on the web, and now Shmeppy is more resilient to a couple of them.

Logins

If someone has a big list of emails they may want to figure out if any of the users they have emails for are using a shitty password across many platforms. So they could try to login to various platforms using various email + common password pairs and seeing if they get any hits.

Since Shmeppy, previously, didn’t limit how many login attempts you could make, you could try millions of these combinations. This is bad for Shmeppy’s users.

If someone is trying to gain access to Shmeppy accounts, they could also use a method like this. (Shmeppy isn’t a very attractive target though, so this seems like a less-likely attack)

But now Shmeppy limits the number of login attempts that can be made across all computers. Shortly, I will release a follow-up change that limits the number of login attempts that can be made by each IP address (easily circumvented with a botnet, but botnets aren’t the easiest thing to acquire).

Email Validation

Soon I’ll be adding a feature to Shmeppy’s “validate your email” screen that tells the user whether their email has been delivered, or if there was a problem.

Once I do this, an attacker who has a huge list of email addresses could try and figure out which email addresses are real by registering for millions of accounts and seeing whether Shmeppy reports the email as being delivered successfully.

To prevent this attack, Shmeppy now limits how many registrations can happen within a short timespan across all computers, and will soon limit how many registrations can happen from a single IP as well.

2

Re: email validation, would it be more secure to just tell the user “check your email for a validation link” without actually reporting on the delivery status of that email?

3

Yes, definitely. But I want to provide the delivery status of the email because Shmeppy’s email delivery is unreliable (and will continue to be for the foreseeable future).

(edit: but to be clear, rate limiting is effective against the attack I described, and I don’t know of another attack that this “email delivery reporting” feature would open Shmeppy up to)

4

i think the best approach for this, security wise is “never confirm or deny the existence of an account with a given email or username”

i’ve seen messages like “if an account exists with this address we’ll send you an email”
here’s a bit more on that : https://postmarkapp.com/guides/password-reset-email-best-practices

5

I am a fiery opponent of best practices and that article highlights the biggest problem I have with the term. The article asserts that a best practice is to never reveal whether an email address is listed in your system, but it doesn’t justify that statement. Saying it’s a best practice is seen as justification enough.

I remember reading a blog post years ago that kinda humorously said something like “why are we doing this again?” in regards to this exact best practice, and made a plea for devs to kindly stop making it harder to know whether a user has made a typo when writing their email address.

6

i believe there’s pros and cons to either approach, and i suppose it boils down to pondering how secure you want a given system to be (tending towards user un-friendliness) vs what security compromise you want to have towards user friendliness.

a targeted attack will be a lot more successful the more feedback the system provides to the attacker (ie: this username/email doesnt exist, or we sent you an email). whereas a bulk attack probably doesn’t care about this feedback and in that case the rate limit approach makes sense.

that being said, a database for an app like shmeppy is probably not worth a targetted attacker’s time as opposed to homebanking/social network/email account etc., which means most of the time you’ll be dealing with automated attacks

7

Anecdotally, I don’t know if that’s true; a disturbingly high number of people use the same password for everything, and a random small-time web service like Shmeppy is exactly the kind of entry point a malicious actor would need to gain access to everything else that shares that password.

Just last week I received a phishing email claiming to have lewd footage of me that they would release to all my friends and family if I didn’t cough up $1001. They cited one of my passwords to me in the email as proof of their “hacking”. While I didn’t recognize the password I did recognize its pattern, one which I retired years ago when I started using a password manager. I ignored the email and life continued as normal.

(My SO, on the other hand, panicked when I told them this story. Turns out they use the same password for everything :roll_eyes: – we’re rectifying that with a password manager very soon!)