[tdrp]

Regarding simple passwords, we added a check against the top 100K seclist passwords when first registering, to keep users from using easily guessable passwords (we also had an experiment where we checked if that password was one of the frequently compromised ones).

Literally this converted into:

1- Users abandoning on sign-ups "oh how am I supposed to find a password I will remember"

2- Users bashing us on the app store reviews: "make it super hard to sign-up" even though we only ask for username and password, not even an e-mail

3- Users logging in, liking the app, then a few months later when they got logged out for whatever reason, completely forgetting what their password was and not having a fallback e-mail.

We ended up pulling it back. We just have a small note now that says "easily guessable password" but allow them to proceed with registration.

[identigral]

This is a good summary of a novel we've been writing based on our experience of tackling similar issues with clients. Working title: Misaligned Incentives. The best real-world solutions we've seen address this issue head-on by providing tangible incentives to the user in such a way that motivates them to act and doesn't harm the overall business objective. Example: product/service discount in a form of a coupon if you register a 2nd auth factor. Finding that balance is challenging, it is very context-sensitive. Selling it to the service owners is even more fun.

[cpeterso]

You could make the minimum password length longer than the longest SecList password. Then users can’t reuse any of those insecure passwords! Plus it’s also a fast O(1) check. :)

[IshKebab]

Yeah that's at least 12 characters though. Quite annoying.

[afiori]

It is very easy to get long passwords, just double them

[cpeterso]

Or just append a long number like "password12345" (13 characters).

[swiley]

Does your app really need people to register an account? I’ve seen plenty of apps that make people sign up when there’s absolutely no reason to require it.

[tdrp]

yeah it's a dating app

[GordonS]

Would social login (Google, Facebook, Twitter etc) be a partial solution here? Basically outsourcing the authentication.

[big-malloc]

The caveat with a third party oauth solution is that you are now dependent and reliant on the third party to _let_ you use them to log in. Here are some fun experiences I’ve had with Facebook over the last couple of years:

- Our app was _deleted_ without any notice and any means of appealing (didn’t appear in the appeals page, and of course there’s no human support). We even filed a ticket and were told that they couldn’t help us because the app was “gone” in their system. Luckily we require an email address or we would have completely lost the ability to authenticate a subset of our users. - A different internal app was banned from using “Facebook Login” because we were “providing a broken user experience” — the app was not even exposed for login in our system. We couldn’t appeal because the warning notice didn’t allow responding from our mailing list. Changing the primary contact didn’t work either, and we even disabled the login on the app just in case. Still revoked with no means of getting it back.

Google has been less awful to work with, but they make you jump through lots of hoops to get public login permissions. In summary, think very carefully about a third party Oauth solution.