Hello HN,<p>I have an idea. What do you think about the concept and do you think that there's an opportunity there?<p>Problem:<p>One of the most fundamental problems in Web security is password reuse, right? For all the communication campaigns and all the alerts that companies send to their users, most users just don't care enough not to reuse their password across websites. And most companies do not dare to force their users to change their passwords regularly. At the same time, these very same companies are the ones getting the backlash when user accounts suddenly get compromised en masse.<p>Goal:<p>What if we had two 'simple' ways of improving security for many users across many websites?<p>1. What if a website could find out, when a user signs up, whether there already exists an identical login/pass "somewhere" on the Internet? Then it could say "eh, how about you chose another password?<p>2. What if a website could find out whether the guy trying to sign in has attempted to log in dozens of other websites in the past hour, logins that were unsuccessful? Then it might be that an attack is going on and the company could freeze the account and alert their user.<p>More information in my comment below (sorry, I kept exceeding the 2.000 character limit)
Solution:<p>Here are the two workflows I have in mind:<p>1. Registration<p>- user submits the form<p>- company sends something like { hash(mail), hash(hash(mail)+pass) } to our API<p>- API returns whether we've found at least a website where this tuple exists (no mention of the website obviously, boolean answer only)<p>- company can refuse registration if the tuple is not unique<p>- When the user finally signs up, send something like { website, hash(mail), hash(hash(mail)+pass) } to our API<p>2. Login<p>- user logs in: fills in the form as usual and submits it<p>- company checks our API to find out whether there have been recent unsuccessful attempts at logging in for the same tuple (mail/pass) across several websites. If so, then there's possibly an attack targeting this user, and the company can take risk mitigation actions such as requiring an sms code or freezing the account until further notice.<p>- if there's no known attack, company checks internally and if it finds out the login information is incorrect, then it reports the bad login to our API<p>Fundamental questions:<p>1. Obviously a major point is ensuring security and trust, that is being able to store data that:<p>- allows finding out whether there is an account with the same information elsewhere<p>- provably forbids attackers and API users from getting more than a non-exploitable answer<p>My opinion is that we can achieve such <i>provable</i> state of security by asking API clients for information hashed in a way that provably prevents us as an API provider to find out more information than needed. Then we can communicate towards companies along the lines of "see how the info you provide us <i>inherently</i> prevent us from getting any sensitive information about your users"<p>2. Well, would you take part in such an initiative?<p>3. Do you know of any company that would actually pay for such a service? 'cause, you know, that would be awesome :)<p>PS Congratulations for reading all of this. Thanks for your input.