Timeline for Password reset giving clues of possible valid email addresses
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 12, 2023 at 23:43 | comment | added | Jey DWork | This answers goes way to short and sets wrong expectations. I'd also hugely advice not to get swayed by an answer like this and really think about the underlying problem like in @DavidMulder's answer (and even here time based attacks were ignored). | |
| Mar 21, 2020 at 20:15 | comment | added | Schwern | @DavidMulder It's not a huge hit until you're the VPN user that gets locked out. I don't know if you've looked at the news lately, but we're about to see a lot more people working from home on VPNs. :grimace: | |
| Mar 21, 2020 at 20:08 | comment | added | David Mulder | @Schwern Having a small fraction of users who will have a slightly worse, but still functional registration form (given it was programmed well) doesn't seem like a 'huge hit' (especially compared to the alternative: a disjoint registration process where you receive an email to continue registering). But yeah, you're absolutely right that considering VPN users is very much worth it. | |
| Mar 21, 2020 at 20:04 | comment | added | Schwern | @DavidMulder My concern with rate limiting per IP is it often locks out legit VPN users, also a huge hit to UX. | |
| Mar 20, 2020 at 22:16 | comment | added | UTF-8 | @DavidZ So let's just check how popular services we all use handle this situation. Idk, maybe SE? So I just plugged an email address not associated with my StackExchange account into the "I forgot my password" form. What did I get? An email stating: "We received an account recovery request on Meta Stack Exchange for [my secondary email address], but that email does not exist in our records." | |
| Mar 20, 2020 at 20:32 | comment | added | David Z | @UTF-8 Do you mean an email should be sent to the address regardless of whether it's registered in the system or not? That seems questionable. I definitely wouldn't want to get emails from some service I have nothing to do with just because someone plugged my email address into a web form. | |
| Mar 20, 2020 at 15:07 | comment | added | UTF-8 | An email should be sent to the stated email address in any case. If there is no account associated with that address, let the owner of that email account know that there has been a password reset attempt. If a third party attempted to reset the password, they know that someone is attacking them. If they forgot which email address they used for registering, they won't wait any longer for the email or think your system is broken but just try their next address. | |
| Mar 20, 2020 at 13:09 | comment | added | Brian | For account registration, you can avoid revealing that information if you make new accounts inaccessible without e-mail verification. None of these techniques are difficult; it's just a matter of deciding whether account existence is secret enough to justify a hit to UX. And of course, you can mitigate the UX issues by sending an e-mail even on failures (e.g., you can send an "account not found" e-mail when a password reset fails). | |
| Mar 20, 2020 at 12:55 | comment | added | Criticizing Israel not allowed | @Christoph "I'd be seriously considering if I use that service at all" is an odd way to write "I'd delete my account and never go back" | |
| Mar 20, 2020 at 11:03 | comment | added | yoozer8 | @davshowhan449 Users should have to accept any ToC when signing up, not during use | |
| Mar 20, 2020 at 8:38 | comment | added | David Mulder | -1 Because you talk about the easiest implementation without even touching upon the related threat model. For example as pointed out in the comments exposing already registered user emails is a typical feature of registration forms, and the important thing is often to prevent brute forcing by rate limiting per IP. Nor do you touch upon the huge hit to UX and the dangers of giving the same response (real users being hurt more than malicious actors) | |
| Mar 20, 2020 at 8:28 | comment | added | Christoph | Are these pages really necessary though? If I had to complete a survey, dismiss several ads and read some ToCs before being able to reset my password, I'd be seriously considering if I use that service at all. Resetting your password should be as simple as writing down my email address and clicking a button. | |
| Mar 20, 2020 at 8:12 | comment | added | davshowhan449 | what if there are pages that come after? like terms and conditions, notices, FYIs, ads, surveys etc. before the actual sending of email? this could affect user experience. A legit user could say, I went all through that and at the end they didnt tell me my email was invalid? | |
| Mar 20, 2020 at 3:46 | comment | added | Alice | But the same thing can be found out via trying out registration. Unless you are saying "registration may or may not be successful" as well, which sounds terrible to me. All in all, it feels like easily bypassed obfuscation at the cost of usability (if a user mistypes his email, he will never find it out and wait in vain). | |
| Mar 19, 2020 at 23:06 | comment | added | Elezar | Plus it just lets the user know what to expect. Yeah, most of us have been through the process before and know that we should look for an email. But for someone who is resetting a password for the first time, you want to let them know what to expect to happen next. | |
| Mar 19, 2020 at 22:59 | comment | added | panofsteel | Legitimate users sometimes forget which email address they used, so it's nice to give them a heads up that the request could fail due to a non-existent account vs. the email getting marked as spam, etc. | |
| Mar 19, 2020 at 22:38 | comment | added | user163495 | Why even add the second sentence? Just give a generic "Your submission has been received and will be processed." | |
| Mar 19, 2020 at 13:35 | history | answered | yoozer8 | CC BY-SA 4.0 |