I was thinking of having a third-party trusted services that compares the hash of the deployed application to the one they independently compiled themselves.
But the complexity is nontrivial and there is enough variations between the output of the same source code across different build environments that would make hashes useless.
Another possibility is having trusted compilers that would send link the source code to the build in a trusted repository.
Upon entering a valid email (whether it is already registered or not) the form will show the following notification "an email was sent to [email protected] with the sign up instructions, please follow the link in the email to continue the registration" (rewrite for more concise message)
If the user already exists the email will be a warning + a link to the password reset form
If the user does not exist, the email will be a link that confirms the ownership of the email address and the rest of the registration process.
An attacker trying to guess if an email is registered would not know, because the form does not give away that info.
And conversion drops right away.
On every of my projects as soon as "auto sign in" was dropped -- conversion dropped as well.
(assuming that the "conversion" is to make a user to register and do something afterwards)
I know that there should be some kind of compromise since any security measure added to secure accounts will lead to some inconvenience for users.
If your goal to make sign in process as smooth for users as possible you may want introduce as little steps as possible between their landing on a page and "purchase".
But verification of email address should be kind of mandatory and happen before something important will be sent to this email.
Many sites allow you to continue, but limit your account and nag you about verifying your email. This seems like more of a happy medium, if you're concerned about conversion.
because if you know someone's email address you have now also discovered that they have an account with a particular service which you should not be able to do.
Can’t you do this anyway on the service? You are assuming there is no rate limiting and the passwords are used directly as bearer tokens to access the site.
But since you are giving advice to the DESIGNER of the site, why not simply tell them not to use passwords? https://qbix.com/blog for example
It's a tradeoff between usability and security, and each site should make their own decision about what is right for them.
It obviously makes attacks like the one in the article easier, but there are other ways to mitigate that.
An example often given for when revealing an email is registered would definitely be bad is dating website and pornography websites - where identifying someone is a member alone could be embarrassing or compromising.
Outside of such scenarios, websites may decide the increased conversion from a more streamlined registration process and lower numbers of support requests for login issues outweigh the marginal security gains from hiding that information.
Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.
It worked instantly.