5 ms·

Wrestling with this now for a side project. I've landed on .NETCore+ASP.NET Identity after getting frustrated with NuxtJS+fastify-auth, but that's really becau

Wrestling with this now for a side project. I've landed on .NETCore+ASP.NET Identity after getting frustrated with NuxtJS+fastify-auth, but that's really because I'm more familiar from my day job and didn't like the SPA road Nuxt was forcing me down. That said, I have a related question I'm hoping the security nerds here can help with: I know it's bad practice to reveal the existence of an account during registration, because it gives an attacker a way to know if a user has an account. So on registration, if the email already exists on another account, you shouldn't say "that account already exists" or do anything that would reveal the account already exists. To me, that means you should always send the user to a "registration successful, check your email" page and then if they already exist, send an email saying it exists with links to password reset & login. That means that the app must be unusable until the user validates their email. But that seems annoying and is not what many sites do. For example, I just tried on shopify, and if the account already exists, they send you to the login page. If not, they log you in automatically. So, for shopify I could in theory scrape using a email list and find who has accounts. To see why this is bad, think of shadier sites (my saas is not). So, my main question: am I making too big a deal about this security requirement or the usability problem it presents? Am I missing some alternative? Related, I'm thinking about letting users send an email to bot@mysaas.com or text 5558675309, which would respond with a "finish registration" or "login" page and auth token accordingly. This would let them skip the verify email step. Is this a bad approach?

bavell 4y ago
I think you should focus on what an attacker gains by your app leaking account existence. Is that knowledge valuable or revealing? If not, then probably not necessary to overcomplicate it. E.g. in the Shopify case, you learn that an email address has a Shopify account. That should be fine as long as they have some rate-limiting in place on their auth endpoint and enforce good passwords. YMMV, I'm not a security expert, etc.
rtev 4y ago
I’ve always liked the way Apple does it. For iCloud, the ‘Forgot Password’ page requires a first and last name. I imagine you could do something similar for registration: if the user email already exists and the first and last name is the same, tell them definitively if the account exists.

bavell 4y ago

I think you should focus on what an attacker gains by your app leaking account existence. Is that knowledge valuable or revealing? If not, then probably not necessary to overcomplicate it. E.g. in the Shopify case, you learn that an email address has a Shopify account. That should be fine as long as they have some rate-limiting in place on their auth endpoint and enforce good passwords. YMMV, I'm not a security expert, etc.

rtev 4y ago

I’ve always liked the way Apple does it. For iCloud, the ‘Forgot Password’ page requires a first and last name. I imagine you could do something similar for registration: if the user email already exists and the first and last name is the same, tell them definitively if the account exists.