Why Passwordless Authentication Works

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

passwordless login

In December 2014, I published Would You Implement Passwordless Login? It expanded on articles such as Justin Balthrop’s Passwords are Obsolete and Ben Brown’s Is it time for passwordless login? The Passwordless project for Node.js has inspired others, including options for PHP and Ruby.

I mentioned considering passwordless authentication for a client project. I’m pleased to say it’s been operating for several months and has been a revelation. More about that shortly — but first, let’s recap …

What is Passwordless Authentication?

We’re using the same authentication methods devised at the dawn of the web. Unfortunately, passwords are increasingly broken:

  • People rarely create strong passwords. Surveys report one in ten accounts use something from the top twenty most popular passwords. “123456” is used by more than 4% accounts; “password” remains the second most-used.
  • People use the same terrible password on multiple sites. If you happen to crack someone’s Facebook login, you can probably access their PayPal account. Your single password is only as good as the security of the weakest system you use.
  • Corporation hacks are increasingly common and attract mainstream media interest. It’s an easy route to make a name for yourself, extract revenge or indulge in blackmail. Few companies are prepared for acts of cyber-terrorism and, despite the usual claims of “sustained sophisticated attacks”, many breaches are simple SQL injections caused by poor development techniques.
  • From a coding perspective, authentication is tedious and mistakes are made. Checking credentials is the start of your problems: you need to ensure there are no cracks in security, hash strings using strong (and slow) algorithms, allow users to reset forgotten passwords and answer support calls from confused users who are seemingly unable to remember or type a short string correctly.
  • Alternative solutions such as biometrics or OAuth depend on hardware or suitable social media accounts. Few sites implement it well, and still need to revert back to email/password methods for some users.

The premise of passwordless authentication is that passwords are unnecessary when the majority of users have secure personal messaging accounts such as email and SMS. Applications can leverage these systems:

  1. To log in, the user visits a site and enters an ID such as an email address.
  2. They are sent a message with a link; they click it and are logged in.

passwordless login In other words, the application creates a random, one-time password, and whispers it to the user whenever they need to access. It’s a similar process to resetting your password — which many users do every login anyway! Email is an obvious choice, but any other messaging service can be used — such as SMS, Slack, Skype, instant messaging or even Twitter direct messages. Multiple options could be offered if you don’t want to rely on a single system.

It’s a little more complex behind the scenes to ensure only one person can use the login link. The general process is as follows:

  1. When entered, the server verifies an account exists for the email address.
  2. The server creates two tokens, such as 24-character hex GUIDs, and associates both with this login attempt. The first token is sent back to the login device — typically as a browser cookie. The second token is encoded in a link sent to the user by email.
  3. When the link is clicked, the server will receive both tokens and verify them against a single login attempt. Optionally, it can make further checks to ensure the link has been clicked within a few minutes and the IP address and browser user-agent string have not changed.
  4. If everything verifies, a real session is started and the user is logged in. If anything fails, all associated tokens can be invalidated; it’s impossible to use them again.

The benefits of passwordless authentication:

  • It’s considerably simpler for users. There are no passwords to create or store. You don’t need a social media account or third-party software other than access to your messaging system. It’s impossible to register without valid credentials.
  • It’s more secure. No passwords are stored and there’s nothing to hack or guess. Even if someone intercepts a message, they’d only have one of the two tokens and couldn’t log in.
  • It’s cost-effective. There’s less code to develop and deploy. Login code is mostly handled by another service with robust security. Your support team is freed from endless password problems.

Where can Passwordless Authentication be Used?

Logging in takes a little longer — but so does using a password manager! Passwordless authentication can be offered on applications which have reasonably long session timeout periods, or where users only need infrequent access. Shopping sites, social networks, forums, ticketing and content management systems are good use cases.

It would be strange to use passwordless authentication on a messaging system, since you’d require another to log in! Nor would you want your bank depending solely on AOL for their security, although secondary identification processes could supplement it.

Passwordless can be considered if you’re creating a new application. However, updating an existing application with many users who currently have passwords is more problematic. I suggest running passwordless authentication in parallel rather than switching to a new login process overnight. Offer it as a choice — especially to users who reset their password — and assess uptake after a few months to determine whether it’s viable.

Real World Test

passwordless login

I implemented passwordless authentication on a new application used by a client for several hundred internal personnel and external customers. Around half the userbase have good IT skills and access daily, so their sessions rarely expire. The other half are mostly managers who log in once or twice per month — many forgetting or mistyping passwords.

The biggest issue: clients must be convinced.

“Passwordless” sounds insecure, and few people will have seen it used elsewhere. I was lucky: the client had a single technically-savvy project manager who understood the concept. Even then, I agreed to add passwords if anything failed.

It was plain sailing from that point onward. For technical reasons, I had to integrate my own implementation rather than rely on a third-party library. It took less than one day, and there was no need for the usual password management, hashing and resetting nonsense which we normally develop and test.

The biggest bonus: users understand passwordless authentication. The process is simple, but it’s best to provide simple instructions at all stages. For example:

  • A login link has been emailed to you. Please check your spam folder if it does not arrive.
  • Please click this link to log in … You have 10 minutes to open this link in the same browser.

No one was confused. No one struggled. No one praised the system but no one complained either; people accepted the process and it didn’t get in their way. The number of password-related login issues reduced from three or four per week to zero.


I couldn’t claim passwordless authentication works everywhere, but the experience has been overwhelmingly positive. I’m a convert. All my applications will be passwordless from now on. Some clients may not be happy — but I’ll just pop a dummy password box on their login form and ignore it!

Have you implemented passwordless authentication? Was it a good or bad experience?

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • My initial thoughts:

    I don’t enable cookies by default. I use Self-Destructing Cookies to manage when and how I permit them. While you can generally expect persistent login sessions to require cookies, but needing them for the act of signing up for an account is not so obvious. You’ll need to make it very clear that cookies are required *before* the user submits the form, or the privacy-concious user will likely suffer frustration.

    This idea could also cause problems for people using grey-listing to manage spam. Any MTA used for such a setup would need to get the message resent with only a very small delay. Some MTAs are setup to do this, but many are not. It would suck to require a link to login that is only valid for 10 minutes, if the e-mail took 10+ minutes to arrive. Of course that wouldn’t be a problem for intranet sites, but you could potentially authenticate against LDAP for that use case, where people are already using the existing password for a bunch of services.

    Lastly, there’s a potential metadata privacy leak associated with sending the message. The Australian government (for example) would know what site was just accessed through the e-mail metadata (if they can capture it), even if you used a VPN to keep browsing habits private.

    Maybe this would work better as a fall-back system for users that enter a weak password (where you wouldn’t even bother saving it)?

    • Craig Buckler

      Thanks boltronics.

      Browsers which block cookies don’t normally stop the technology but expire them at the end of the browsing session. Passwordless authentication will still work unless you close your browser – but that’s the same for any normal ID/password authentication.

      If messaging is delayed you could have issues. You’ll need to assess whether that affects a significant proportion of your user base and, even then, it’s a normally short-term problem. You can offer more than one messaging alternative if it remains an issue.

      As for a meta data leak, there are many ways for governments to know what sites you’re accessing. In the UK, they’re considering legislation which forces ISPs to store all browsing data for one year. Even with a regular ID/password, you normally receive some sort of registration email or may need to use a password reset.

      Overall, passwordless no less secure or troublesome than using an ID and a very strong password.

      • Regarding cookies, that sounds pretty good then. Thanks for clarifying.

        Grey listing is the process of having your MTA bounce e-mails from a sender it hasn’t seen before, with an SMTP 4XX temporary error code (eg. 450 “mailbox unavailable”). Spammers often won’t bother retrying something that didn’t work, since they’ll have millions of other addresses to try, so grey listing is a very simple and effective spam filter solution. But the length of the delay will be entirely up to the MTA that sent the original e-mail, so it’s up to the maintainer of the website to keep this in mind. If you, the website developer, controls the mail server and keep this in mind, it’s a problem easily avoided. If e-mail is outsourced where you have no direct control, it’s likely a problem.

        Australia very recently got the whole mandatory metadata retention thing, so as an Australian I’ll want basically all my data going over a VPN to another country that’s not one of the Five Eyes. So it is possible to avoid metadata collection for browsing habits (since the ISP will only see a single VPN connection to another country), but if your e-mail is still hosted in a FVEY country and you receive a sign-up e-mail from a website, that activity still ended up logged by the government.

  • Patrick Catanzariti

    Hi Craig! Great article :D What are your thoughts on Steve Gibson’s new SQRL approach to authentication? https://www.grc.com/sqrl/sqrl.htm I’m intrigued by it but haven’t looked into it in depth yet! it fits in well with what you’re speaking about though :)

    • Craig Buckler

      Thanks Patrick.

      I like SQRL. However, in situations where the user doesn’t have or can’t use a smartphone, I’d suggest falling back to passwordless rather than a regular ID/password. It’s also a great option for secondary authentication if you want more robust security for banking or shopping apps.

      • Doug Smith

        SQRL does not require a smartphone. This is a misconception from the early days where the idea first started. You can either scan the QR code or click / touch the link that is included with it. It does require an app to handle the sqrl:// url, which could be a stand-alone app or capability built into some other app, such as a password manager or browser.

        SQRL is also not really designed to be a second factor. It’s designed to be a very secure single factor that is sufficient on its own.

        The project is completely open and very well documented. If you haven’t looked at SQRL in the last year it’s worth checking out again because the protocol and documentation have been really fleshed out.

        • Craig Buckler

          Thanks Doug. That’s interesting. The requirement for an app could still be a step too far for some, but it’s still a far better solution than IDs/passwords.

  • What a great idea! Thanks Craig :)

    • Craig Buckler

      I can’t claim credit for the idea but do recommend it!

      • Rebecca Shetler

        So far this year I have earned 68,000 dollars with my pc and I am a college student . I am connected with a business entity that outsource online jobs . I heard about it last year and I have made such great cash . It is great and I am just so happy to have that option ……. Look here for details …


  • Tiago Braga

    Very good job on this article!
    Thank you for sharing these ideas! :)

  • Mark Williams

    Great article Craig.

    I love the idea of dropping passwords. The amount of login issues they cause is a real problem. For some clients I end up wasting so much time looking into “login issues” when almost all of them are caused by wrong passwords entered.

    Having never used such a system, so I can’t speak from experience, I wonder if I would personally find this more of a pain than using passwords (from the perspective of a user). While not very secure I would say a lot of users (at least the more tech savy ones) tend to store passwords in their browser so it’s very simple to login. I think I would find the method of having to wait for an email and then click a link much less convenient, maybe bordering on being annoying. I would just wonder if it might actually put some people off using the site all together and of course you may never get feedback from these people.

    Have you ever had people not receive their password due to spam or have it arrive after the 10 minute timeout period? That’s another element that would concern me.

    However I would tempted to give this method a go on a new application I am building.

    • Craig Buckler

      Thanks Mark.

      Passwordless wouldn’t work everywhere. As mentioned, if you have short session timeout periods or expect users to log in frequently it could become frustrating. Fortunately, that affects few sites.

      I’ve not had problems with email delays. Perhaps I’ve been lucky but I suspect that email arrives promptly for most people. That said, on a system with a wide variety of users I would certainly consider multiple messaging methods.

  • Great article! I never implemented a passwordless authentication but you just convinced me to give it a try. :)

  • poisonborz

    That’s a stupid idea actually.

    So instead of granting the user the ability to choose password per service, you’re tying possibly multiple services to one password, to the user’s email account (of course mail accounts can also have two-step verification, but the process would be even more awkward then). Just getting access to a victim’s mailbox would grant access to all these services. The end result is a method that is both weaker and slower.

    The only application I could envision is novel apps where the user would register a throwaway account anyway.

    Until biometric authentication will be widespread – that is, until most mobile devices will feature them, universal/pc attaching devices are sold, and necessary protocols become available (eg. a web standard for utilizing them) there won’t be really a better solution than passwords.

    • Craig Buckler

      It’s no weaker than your email’s security – which is normally more robust than most. Most users keep their email open so it’s not as though you’re asking them to log in again.

      The vast majority of ID/password systems offer a reset password facility. If you can access someone’s email, you can change their password. Passwordless is no less secure.

      • I agree that password reset facilities that just ask for an email address may not be so secure (as opposed to email + secret question), but this solution is basically using an email account as a password manager. I’ve seen too many average Joe users email accounts get hacked. Especially those on Yahoo for some reason.

        An OTP sent via SMS would be a bit more secure I would think, as people guard their mobile phone more than their email. E.g. someone might go for lunch with their computer on and email logged in. They will always take their biometric phone with them.

        • Craig Buckler

          Even if a hacker accesses your email, they need to know you have an account on a specific system. If you delete login emails that won’t be obvious.

          That said, if someone can access your email account, accessing a specific system is the least of your worries. They could commit identity fraud, empty your bank accounts, buy stuff, con contacts etc.

          • “That said, if someone can access your email account, accessing a specific system is the least of your worries.”

            This would be the case for a random hacker trying to take over your identity. I was talking more about a targeted attack. A real world use case for which I considered using this approach and then decided against it (somewhat similar to the one you mention in the article) :

            I have an HR app that runs on the client’s intranet. If someone in the company wanted to illegally access this system, all they would need to is to figure out a way to access the desktop of an HR staff (not particularly difficult). Once inside, email will open on Outlook without any password.

          • Craig Buckler

            Interesting, but I think that says more about the security of their email system than the HR system! However, on a corporate network you shouldn’t need extra additional logins or passwords because apps can use LDAP/similar.

          • Richard

            The same goes for a hacker trying to hack directly into an account on a specific system. How do they know that I have an account on that specific system? They don’t, unless the system responds with “There is an account for that email but the password is wrong”.

            If all email accounts enforce multi factor authentication, then I would say that passwordless using email would be feasible.

    • I agree with you. If everyone implemented this type of system, it would be no different than using the same password on every system independently.

      The biggest pitfall for me though is usability. What a nightmare! Why would I want to have to open my email client every time I want to log into a web service? Then I’ve got two windows/tabs open and I have to go close the first one.

      I can see the benefits of passwordless authentication, but frankly it’s just not a viable option from a usability standpoint. I would actively avoid using a service like this and I don’t know a single client who wouldn’t feel the same way.

      This does nothing of mentioning the biggest pitfall of all. It removes user input from the equation. This means that the user is no longer unique to the system. What happens if someone steals your laptop or phone and has access to your email account? You’ve just given them the keys to your entire life. This is a horrible nightmare for corporate security as well. All you have to do is step away from your computer for a second. Sure, employees should be taught security standards, but they are still going to act human and make mistakes. At least when they have to remember a password, simply gaining access to hardware is not enough.

      Passwords have been in use for so long because they work. Until biometrics or some other system becomes popular that can link an account to a specific person, there really isn’t any better option than the legacy systems we have now. We just need to teach people to choose better passwords (such as passphrases) and stop forcing them to create illegible passwords that are hard to remember and easy for computers to crack anyway.

      • Craig Buckler

        Usability: how often do you log into something like Facebook, Twitter or LinkedIn now? Rarely, if ever. It’s the same with passwordless. Perhaps I didn’t state this clearly enough but don’t use it for systems with short session timeouts.

        Security: if someone can access your email account (and know you have an account elsewhere) they can access your passwordless system. However, they can do that with most password-based systems too. In fact, you can do it without hacking email or stealing hardware since people use simple passwords which can be cracked in seconds. (In addition, around half of the web uses GMail which offers secondary authentication and access tracking).

        You state “passwords have been in use for so long because they work” then contradict that with “we just need to teach people to choose better passwords”!

        Passwords have been used for so long because we don’t question their use. I’m not saying passwordless is a magic bullet, but the benefits outweigh the risks for the majority of systems.

        • Richard

          “However, they can do that with most password-based systems too.” I think this is the point the guys are trying to make, that it’s not more secure than using a password directly.

          • Craig Buckler

            I don’t think anyone’s stated it’s more secure but it does guarantee people don’t use simple passwords or forget them.

          • Maximilian

            And how are the email accounts secured? Oh right, passwords, the same simple passwords they would’ve used everywhere else anyway. All this does is paint a massive target on the backs of email providers.

          • Craig Buckler

            That’s the whole point. You already have a password-secured system – why reinvent another?

            Why would email providers become more of a “massive target”: they are already. Any system which implements password hints or resets is only as secure as the email system it uses.

          • Maximilian

            But it doesn’t solve the inherent weakness, it just bottlenecks it in one source and becomes a much easier target. It’s not difficult. If you want to hack into one account on one website then you bruteforce that password or whatever method you want to use. If you want to hack into 10 accounts on 10 websites then you have to do that 10 times. Bundling every account into one email address that will likely have just as crap a password means that cracking that one password gives a hacker access to EVERY account.

          • Craig Buckler

            What you are saying is true for every system which allows password resets. If you can access someone’s email account, you have access to everything and can reset passwords everywhere. How is passwordless worse?

            Besides, your email security is likely to be superior to any account management system you devise. For example, Gmail provides 2-level authentication and warns when the account is accessed from new devices and locations.

            Even if you get access, it doesn’t follow you’ll know every system the user is using so it’s a large trial and error process for any hacker.

    • djr

      Any modern service you’ve ever signed up for sent you email. If you haven’t deleted those emails, and someone hacks your account, they can reset passwords and log into any of those accounts.

      Passwordless auth is at least as secure as passworded auth that allows resetting the password through email. And there are fewer headaches — secret keys can be cryptographically strong (don’t need to remember them), can be recycled often (also because you don’t need to remember them), and they are different across accounts — if someone hacks one account, they don’t gain any info about another. Currently, people use the same 1-2 passwords across dozens of accounts, or 1-character variations of one password. Worst, they use their email password for all their other accounts, in which they log in with their email as username.

      Passworded auth is totally busted because in order to work, it requires people to remember lots of hard to guess stuff (really long passwords, a different one for each account), which is just a horrible assumption to build high-grade security on.

      However, maybe the thing to question is whether it’s secure to use email as backup authentication. I think email backup is not good, but it’s the same flaw in passworded auth (using email for reset link). It’d be better to use a physical device (e.g. SMS to the SIM card in your phone) and the strongest way is obviously biometric.

  • What I’ve typically seen services (like my bank) do is to send a numeric pin number (one time password) which can be entered into the website on your desktop.

  • Hi,

    This was really useful. I’m wondering though: for a mobile app (no desktop interface/web interface) that needs low security, and only needs one factor auth, is there a preferred approach between SMS push codes and secure email links with tokens? The app I am designing requires a numeric passcode; we would be using a passwordless means to allow the passcode to be reset and wasn’t sure which was better (primarily asking from a technical security perspective but open to other ones). Thanks!

    • Craig Buckler

      I think you’ll need to do some research to find out what technologies users have and are comfortable with. SMS is likely to be the lowest common denominator but there may be a cost associated with sending messages.

      • Hi- this is done. Sms or email are both available. It’s not a human factors or ux question, just a security one I was asking about. Roger on the cost side for SMS.

  • Craig Buckler

    As Dinu says, it doesn’t need to be a link – it could be an access code.

    You just need to be wary about the use cases when developing your app. For most people, email is fine though.

  • Ashley

    Isn’t it annoying to have to switch back and forth between the site you were trying to login to and your email? I don’t understand how users are ok with that.

    • Craig Buckler

      It absolutely would be if you were logging in and out several times per day. Is that what happens on your app? If so, don’t use passwordless.

      The app I used it on has a long timeout period. Some users login once and never again because they’re accessing daily. Those who use it infrequently don’t mind because they’re logging in rarely and don’t have to invent, remember or manage passwords ever again!

  • Nuwanda

    It’s an intriguing idea where the only real downsides are in the UX.

    That said, it pays to observe your clients and how they use their accounts. Case in point: one of my clients never bothered to remember their password and always used the email reset to log in. I asked them about it and they told me that after having to do a password reset a couple of times they realised it was a foolproof solution to remembering a not often-used password.

    Even the extra steps they had to take (click reset link, enter new password, log in with new password) weren’t an issue. It was easier than having to remember or look up that pesky and complex password. And I suspect many other users I deal with adopt the same solution. Until you observe users in action you don’t realise how bizarre things can get. But contained in that convoluted behavior are often hints as to how problems could more easily be solved.

    That said, I think passwordless access is more suitable for in-house or tech-savvy users.

    • Craig Buckler

      Actually, I think it’s the novice users who benefit most. Tech-savvy users tend to understand the importance of good passwords and may use software to manage them. Novices use the same simple password everywhere and will forget that or use the reset facility (which is just passwordless with a few extra steps).

  • swards

    Craigslist has been doing this since the beginning I think. It’s a a good site for this UI, people don’t come back to the site everyday, but when they do they need to access their account. A little extra time was worth it and made the onboarding process simpler. It was only later they added passwords.

  • wyattb

    This would be useful for users who do not use OAuth accounts (gmail/fb/twitter). Can you improve password-less UX with a specialized email/sms reader app to check your email (can be browser or thick client) and popup a notification to click and login?

    • Craig Buckler

      There are many possibilities. For example, you’re probably logged in to your browser – something like Mozilla Persona could handle the process without you having to rely on email.

      That said, any solution which requires downloads or configuration is a step too much for many users. A big advantage of passwordless is that’s it utilizes what the user already has and understands.

  • Dominic Huang

    Interesting post! Will Passwordless Authentication affect the business like 1Password?

    • Craig Buckler

      I doubt it. Systems with passwords will exist for many years (unless quantum computing becomes viable). Even if many adopted passwordless you’d still require passwords or other authentication for email and other messaging systems.

      The biggest threat to 1Password are free/open-source alternatives such as KeePass.

  • Max Beggelman

    I see two big weaknesses here. First is the user flow interruption, particularly in mobile and other devices. You have to navigate out of your browser and into an email client, find and view the email, then either click a link (which will typically open in a new tab in your default browser) or copy some text/a URL and return to your browser to paste it. The process doesn’t necessarily take that long or involve that much work, but on mobile devices it can take more taps and time than just typing in an average-length password, and on embedded devices it can mean having to pull out a different device entirely. And if there’s even the slightest delay in sending the email, that further interrupts and aggravates users (as anyone who heavily uses two-factor authentication likely knows).

    Also, there’s the security aspect. “Click this link in your email to log in” isn’t something I’d really want users to get used to, due to the phishing implications. Being passwordless means there’s no risk of the user’s authentication with your service being stolen directly, but a phisher can still trick the user into entering other private information that can be used for identity theft or attacks against the user’s account with other services. I agree with the general sentiment of moving away from passwords (it’s somewhat ridiculous that anyone could potentially steal vast swathes of your personal information just by guessing a magic string of characters) but the implications have to be regarded with caution, especially since passwordless isn’t suitable for every service.

    • Craig Buckler

      I agree that passwordless isn’t suitable everywhere but it would be fine for many services.

      With regard to user flow interruption, how many times do users forget or mistype passwords? That issue disappears with passwordless. I accept it’s a little effort to open an email client but it’s not something you do often if you have a reasonably long session timeout or use the service regularly. No one has complained on the system I’ve been testing and, while that’s not an exhaustive test, I had expected some negative feedback.

      Phishing is an interesting point although people click links in email all the time! The phishing email would have to arrive exactly when they expected a passwordless login link to not arouse suspicion. Even if they clicked it, most phishing systems attempt to extract passwords – which users don’t have.

      Passwordless isn’t a magic solution but it’s worth considering.

  • Olivier Caron-Lizotte

    Here is my take on securing genetic data using the passwordless approach:

  • Kevin

    No. The tokens are only created at login time, and while they could be stored in the database, they expire in a short time (for example, 10 minutes as suggested in the article). Of course it could be (even likely) that some users are in the process of logging in when the database theft occurs, the chance that the thief could find those users in the database quickly enough is minimal at best. Plus, the system requires the user to complete the login from the same computer/browser/IP so the thief would have to impersonate the user on that level as well. To be clear, I’m not convinced that passwordless is workable in very many situations, but just not for the reason you stated.

  • Craig Buckler

    You could check for that, e.g. any attempt at login must be at least N seconds since the last attempt. A simple pause of 10 seconds or so would prevent many issues.

    Besides, is it really a problem? Sure, you get 100 emails (which Gmail and others would show as one “conversation” anyway). The time it takes you to ignore or delete them is significantly less effort than the person who sent them!

  • Craig Buckler

    If someone steals your database, random tokens are the least of your problems!

    As Kevin points out, the token isn’t the only form of authentication. The token on its own is useless and, if necessary, the administrator could wipe every one in seconds so they’re all invalidated.

    A standard password must be stored (in a hashed value but some sites still use plain text). The Ashley Madison hack managed to decrypt every password in a matter of days. Those passwords remain valid unless you reset them and send all users an email … like passwordless does every time!