41–50 of 202 posts
> we believe we addressed the issue before it was exploited by any malicious parties I wonder how they are sure of this. In their logs, there would be no difference between a legitimate password reset and a malicious one, given that even a legitimate flow would result in an initial request from some IP address, then when the user receives the email with the reset link they will most likely click on that from the same…
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…
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".
> Hey, do you have a Grindr account? > Lol I can understand this is most probably a private lol by a surprised. But how about we at least stop making these are you gay? Lol! a public moment worth screenshooting? An Ashley Madison data leak is a national embarrassment whereas a Grindr one, a "national security threat" [1]. Being on AM is just a vaudevillian indiscretion, being on Grindr is bro lol that feeds hate and…
[0] https://www.independent.co.uk/news/world/middle-east/egypt-l...
Earlier quoted context omitted.
Not saying they did, but couldn't you make an estimate by looking at frequency of resets by single accounts? If someone took over an active account presumably that person would reset the password to get back in (and have a weird email). ASSUMING Grindr logs the person out of the app when the password is reset. You might also have a few emails from users...
This would detect a large-scale attack, but wouldn't detect small-scale, targeted attacks as they would just get lost in the noise of legitimate password resets. Furthermore, for dormant accounts (where the user is no longer using the app - potentially because they are now in a relationship) the user will not notice anything either, and the notification email is likely to get lost in the endless newsletter spam the n…
And yeah I agree that this type of analysis wouldn't help with dormant accounts and also does require them to log the user out on their phone (otherwise why issue another reset?). But both these could be captured. This is probably way too much analysis for such an attack and over engineering the issue, but hey that's what we all do, right? haha
Reaching out to their CTO, who I found on LinkedIn, and firstname.lastname@grindr.com got a reply in 8 minutes.
Sad to see they still haven't upped their security game.
Earlier quoted context omitted.
someone designed and implemented it. Would be interesting to know the rationale and their train of thought leading to that.
I mean, I don't think it's that hard to surmise how something like this could have happened. Yes, the bug is egregiously bad, but I don't think it's likely the developer purposely designed it to work like that. Some simple possibilities: (a) perhaps the page was originally intended only to be accessible from a user hitting from a private link sent to their email address (i.e. how normal password resets work, or (b) T…
Whatever API this is using, there's zero reason to show any information about the request other than "we didn't die, so it should succeed". Beyond even showing it, there's zero reason for a password reset API to respond to the request with the secret at all. If it needs to return anything identifying about the request, it should be some identifier that is NOT the secret, which can be used to pull up general info about the request later if needed (time generated, whether it was used, is it expired, etc). Extra points if the access credentials to any back-end API the request page uses can't even request the secret key from a request.
A sane API makes it very hard for something like this to happen. Often that takes an inversion of thinking, so instead of making an API as useful as possible and return as much data as efficiently as possible, you make to make it as secure as possible, which means returning as little data as possible to satisfy the specific needs of the use case, and different locked down credentials for specific use cases.
Earlier quoted context omitted.
This would detect a large-scale attack, but wouldn't detect small-scale, targeted attacks as they would just get lost in the noise of legitimate password resets. Furthermore, for dormant accounts (where the user is no longer using the app - potentially because they are now in a relationship) the user will not notice anything either, and the notification email is likely to get lost in the endless newsletter spam the n…
I think this is a good point. I'll admit that I'm naive about web and security (not my area). Are multiple password resets within a small time frame common? I would not expect this to be common, but user behavior has often defied my expectation. If it is uncommon I think you could create a correlation and get an estimate, if it is common then I completely agree that it would be lost in the noise. And yeah I agree tha…
However the biggest risk here is that small, targeted attacks distributed over time (where a single attacker only targets a handful of accounts) wouldn't stand out in the overall statistics.
In case of this incident, small-scale attacks (where a single person targets a single account of someone they don't like) are actually more likely which is why them saying they do not believe this was exploited while being completely unable to detect these attacks is so misleading and lures people into a false sense of security.
> we believe we addressed the issue before it was exploited by any malicious parties I wonder how they are sure of this. In their logs, there would be no difference between a legitimate password reset and a malicious one, given that even a legitimate flow would result in an initial request from some IP address, then when the user receives the email with the reset link they will most likely click on that from the same…
They don’t mention any, so this is the most positive sounding but still truthful position they can take.
Best I can think of is geolocating IPs of the reset requests and then seeing if the real owner (near original location) does a second reset later to take the account back, but that’s not convincing especially if you know where the account you’re targeting lives and went through a VPN in the same city to match.
> we believe we addressed the issue before it was exploited by any malicious parties I wonder how they are sure of this. In their logs, there would be no difference between a legitimate password reset and a malicious one, given that even a legitimate flow would result in an initial request from some IP address, then when the user receives the email with the reset link they will most likely click on that from the same…
Since when do beliefs require evidence? They don’t mention any, so this is the most positive sounding but still truthful position they can take. Best I can think of is geolocating IPs of the reset requests and then seeing if the real owner (near original location) does a second reset later to take the account back, but that’s not convincing especially if you know where the account you’re targeting lives and went thro…
They are supposed to be the experts (in the eyes of non-technical people) and if you don't have the skills to understand how the attack works it's reasonable (or at least used to be reasonable) to consider that the risk is minimal if "experts" do not believe it's bad.
This response lures their users into a false sense of security.