[perardi]

OK, I know it’s easy to say “well of course it’s not safe, don’t send nudes and don’t go on sketchy hookups”. But, to paraphrase Drag Race: men are rotted gila monsters. (I’m a gay male, I can say that. Also I speak from experience. I've seen things you people wouldn't believe.)

So, as a thought exercise, how do you make an app like this more secure? Harm reduction is the name of the game. What are the best practices for this? Is it 2FA? Is it encryption keys linked to one device? Is it copying principles from Signal? Is it just having competent developers?

[sebmellen]

Uh... One part of it is not returning password reset tokens in the browser. If you know remotely anything about web security this is the most glaring security flaw you could ever encounter.

Other steps are nice to think about, but ensuring basic security measures would preempt 99% of data breaches and "hacks".

[brundolf]

The most appalling part is that this was a dedicated endpoint, named "password-reset". This wasn't some negligent leak, some misconfigured logger. It was done this way on purpose. Somebody thought this was a good idea. And nobody else saw it and thought to question it! It reveals gross institutional incompetence that probably should have been filtered out at the hiring stage.

[ghostbrainalpha]

Could you explain why that's bad for someone who knows nothing about security?

Where should the password reset token be?

[sebmellen]

The token should only be accessible to the user requesting the password reset, meaning that it would be sent via email (this is the standard password reset flow).

The flaw here is that anyone, even if they did not control the email of the user, could reset the password, because the reset token was returned in the browser, where anyone could see it. Essentially, just by knowing someone's email (not having control over it), you could reset their password.

[ghostbrainalpha]

You did a really great job breaking that down! Thank you!

[Jtsummers]

It should’ve been sent via email to the registered email address. That lets the account owner reject it (I didn’t request a password reset!) or use it.

[dewey]

In an email sent to the address linked to the account.

[perardi]

Yeah, in this particular case, they were just glaringly stupid.

Just gaming out ideas in my head. I have friends from rather more repressive countries, namely China, where being gay is still a grey area in terms of legality and acceptance, and I’m just thinking of better ways to structure a system.

[thaumasiotes]

> rather more repressive countries, namely China, where being gay is still a grey area in terms of legality and acceptance

...what?

[DoreenMichele]

Unfortunately, a large part of it can only really be solved by making the world and the laws of the world safer for the LGBTQ community.

I do what I can in terms of promoting certain ideas, creating informational resources, etc. But I am just one person and yadda.

As long as it is okay to jail or kill people merely for being gay, no amount of security will ever really make it safe.

In the meantime, perhaps someone should blog about "dating security best practices for the LGBTQ crowd" or something like that. (It won't be me. I'm just tossing the idea out there.)

[franga2000]

For the communication part, E2E encryption is the obvious choice and the Signal Protocol is a great candidate. They could either implement it themselves or make a deal with Open Whisper Systems to dual-license it (not 100%, but I think that's what WhatsApp did).

The problem here is the profiles, which can't be E2E encrypted because the server need to run matching algorithms on them. This is where hiring competent developers comes in, along with semi-regular security audits.

Regarding this issue specifically: as far as I'm concerned, a password reset endpoint should return absolutely no information, which should be enforced by an integration test. And I don't only mean the HTTP body here - even the return time of the request (check db, send email if user exists) could be a user enumeration exploit, which for a gay dating app already sounds like a big problem. Throw the email into a queue and return immediately. Have a background worker deal with asynchronously. Add a random sleep() if you can afford it. if resp.code == 200: "If the address was correct, you will receive a reset link"

In many parts of the world, you could be risking people's lives by having a side-channel user enumeration bug, let alone this level stupidity. But I doubt your average overworked "full-stack" JS dev would even think about this, and the incentive structure simply isn't there for a for-profit company to hire people that would.