Legacy authentication service — seldom touched. How the password should look like when migrating it to a new authentication service?
“Check Google, they support only ASCII letters”
“NIST says non ASCII letters should be supported”
“If non ASCII letters are supported, bcryt needs sha512 to fix the issue” https://medium.com/@sendoh-daten/using-bcrypt-as-password-encoder-can-be-problematic-when-passwords-are-non-ascii-characters-a5ac0478aeed
“The length of password should be more than 12 characters”
“But our legacy restricts to 6. Should block those users who don’t have more than 12 characters?”
“User should know how strong is the password”
“User should not use common password”
“How the user know they use common password? User feels frastrated about the password cannot be used”
“and check how often the user requests forgot password/reset passowrd? So often”
The effort of migration of auth sums up to be incrediable.
The most important thing is
“User hates password” and 2FA is more secure than password. (My legacy auth service doesn’t support 2FA)
So all these efforts about password do not help UX or security that much.
If time goes back, I’d not touch password and only provide Sign-in with link (https://auth0.com/docs/authenticate/passwordless/authentication-methods/email-magic-link).
Linkedin and Slack support such approach.
The following data shows the information from Auth0 about password https://auth0.com/resources/whitepapers/passwordless-authentication
- Industry experts generally agree that each password reset costs a company $70
- Auth0 has seen costs as high as $120 per password
Conversion rate
- For some companies, eliminating passwords has improved conversion rates by more than 50%.
- Ditching passwords and increasing ecommerce conversion rates by 54%
Sign-in with link doesn’t need password, and also doesn’t need the time to discuss with security analyst, UX, product, devs about the password rule, and is even more secure (My legacy auth doesn’t support 2FA, and the new one also doesn’t support 2FA so far).
The email is also verified/updated via Sign-in with link which GDPR requests you need to have a way to inform the customer about T&C. Marketing also likes it.
I still have this issue opened that how to make sure the user’s email is updated from legal and marketing.
My advice: if you are migrating your auth service or building a new one, save your time and effort and don’t support password. Simply provide sign-in with link and wait for FIDO (https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html, https://developer.apple.com/passkeys/)
Oh my precious time! 😢 And Medium is using sign-in with magic link and doesn’t use any password.
