These days, a password is, more often than not, a single-use affair. One hurriedly settles upon a password while signing up to some new account or other. By the time one needs to sign in again, the password almost invariably eludes the memory, resurfacing only after the password reset process has been completed.
This poses something of a problem in XMPP-land. In an attempt to keep data collection to a bare minimum, many servers ask only for a preferred username and password. With no further information, how can they verify it's really you in order to reset your password? And if you don't go through the motions of resetting your password, what hope does your memory have of retrieving the old one?
To prevent their users from being locked out of their accounts, some XMPP providers allow you to set a recovery email address, to which password reset details may be forwarded when the occasion arises. Allowing for the privacy-minded, this recovery email is often made optional: a good thing, though unfortunate for those optimists who think they will remember their passwords without fail, until they realise they actually don't.
A bigger drawback with this setup is that, as of now, such extra fields are not supported in the in-app registration process. Server operators usually make custom HTTP pages for registration, which can collect all the additional information. This works effectively, but it means the user has to leave the app and (manually) open a web browser to complete registration before coming back to the app and (again, manually) entering their newly acquired login details. Perhaps not a major inconvenience on the scale of things, but certainly so on the scale of "hyper-polished corporate-backed apps that make it so easy to sign up you could almost do it by accident"!
As an aside, sending the user to an HTTP page to sign up is not necessarily a bad thing: it does let the server operator show off a bit more of their website and potentially highlight the fact that theirs is a service run by people, not merely some faceless corporation.
That said, I think it would be nice if, having taken the trouble to download and install an app, users could get started without having to leave it again.
To better blend in with the faceless corporations, Quicksy and Prav have reasoned thus: if people are going to reset their passwords almost every time they log in, why not use the password reset process as the default way to log in?
This is possible because Quicksy and Prav control both the client and the server of their respective services. Their "signing in" process involves entering a phone number to receive a one-time code on it, which can then be entered to authenticate the session. Internally, this is the point at which a new, randomly generated password is set for your client to use in future communications.
As you can see, it is, quite literally, nothing but a password reset process.
A problem with this is that signing in on a secod device will change the password, rendering the account inaccessible to your first device. A workaround is to directly view or set the password on your first device, and enter that password on all subsequent devices to sign in the "normal" way. Of course, that means you lose out on the "passwordless" part and are back in the whole password routine.
Fortunately, the future seems to hold ways in which we can not only go passwordless, but also remain so.
When a client connects to a server for the first time, it usually has to authenticate itself—whether by a password or through some other means. But what about after the first time? That's where XEP-0484 or Fast Authentication Streamlining Tokens (FAST) comes in.
Once a connection is made, FAST lets the server give a special token to the client, which the client can then use for future authentications. Practically, it's almost like the current Quicksy and Prav routine of setting a new password each time—except that the "password" is client-specific and doesn't affect the ability of the other clients to continue logging in.
FAST tokens have an expiry date, but one that can be automatically extended—so while your client that has been offline for two months may need re-authentication, the one that has been logging in every day for two months won't.
FAST solves the problem of "having to set a password after authentication" but what about the authentication process itself? This is a problem in two parts, because there are two different situations in which you'd want to log in to your account: the first time, and every time that comes after.
The first time you want to use XMPP, you don't have an account yet: you have to sign up or "register" one. The ubiquitous XEP-0077 In-Band Registration (IBR) defines a standardised way to do just that...but with a username and password, and, worse, with only a username and password. XMPP providers that want to collect more fields, such as an email address, or use something other than a password to authenticate, like a phone number, have to either host an external HTTP page or customise the client itself.
Or, they could use something like the experimental XEP-0389 Extensible In-Band Registration (nicknamed IBR2 or extensible IBR). This XEP replaces the single "username and password" form of IBR with a series of "challenges" and "responses", where a "challenge" can be simply "what's your preferred username and password?" but could also be "check your SMSes and enter the code we sent you there" or "enter the numbers in reverse order to prove you're not a robot". Like the original IBR, the extensible version is backed by XEP-0004 Data Forms, making it truly extensible to anything you want it to be.
For the HTTP-happy, there is "out of band" registration which automatically opening up a web browser and reads the response when done. This means server operators can potentially keep their existing web-based signup pages, but allow them to be seamlessly opened and closed by the app itself—possibly the best of both worlds.
Once you have an XMPP account, the current standard way to sign in is to negotiate an SASL connection, which decides the security features of your "stream"—the XMPP connection—but usually also involves your client passing in your username and password at some point.
Similar to extensible IBR, XEP-0388 Extensible SASL Profile builds upon the normal SASL negotiation process to let you add other options to the mix. The XEP gives an example of second-factor authentication through TOTP, but one can imagine using a challenge mechanism similar to extensible IBR to make a one-time code the only factor, rather than the second one.
Taking things a step further, perhaps we could handle new users by merely adding a "challenge" of "what username would your prefer?" thereby eliminating the need for "registration" altogether? Is there really that much difference, after all, between logging in for the first time and loggin in every other time?
The standards-minded reader would have noted, with some alarm, that by blithely using "authentication through SMSed code" we are replacing a truly independent and decentralised authentication mechanism—the password—with a rather more centralised one.
Fortunately, SMS is only one example. The same authentication code could just as easily be delivered by some other means, such as through email via SMTP, within an existing webapp, on a different messaging network like IRC...
...or through XMPP itself, to an already connected client of the user's. This would allow a user to sign in with a new XMPP client by authorising it using an already existing one.
While there is no XEP yet for "sign in to a new client by authorising with an existing one", there are a few bits and pieces that could be put together.
The simplest option is, of course, to do what we do on other networks and simply send an ordinary XMPP message saying "your password is so-and-so".
More interesting in XEP-0070 Verifying HTTP Requests via XMPP. THe original purpose of this XEP is to let an XMPP client authorise access to an HTTP client such as a web browser. When your web browser tries to load a page, the HTTP server forwards the request to your XMPP server, which passes it on to your client. On your end, you'll see a popup saying something like "Hey, should we allow browser with code so-and-so to access this page of yours?"
While it may matter to you whether the request originated from an HTTP request or it was just your server making things up, your XMPP client doesn't care. All it knows is that the server has sent an XEP-0070 authorisation request, to which you can answer either yea or nay.
That makes it a small matter for the server to "make up" an authorisation request when you try to sign in from another client. Any client with XEP-0070 support can handle it. It matters not if the original trigger at the other end is the SASL negotiation process for your newly installed chat client, rather than an HTTP request from your not-necessarily-newly-installed web browser.
Ironically, this setup would be quite helpful for web-based XMPP clients, where people may not be comfortable entering their XMPP passwords. Now, they can just authenticate the webclient via some other client instead! Needless to say, if this becomes a regular feature, it would be a good idea to define it as such in a separate XEP. This would allow for more levels of protection, and perhaps encryption key verification as well.
Wait, the security-minded reader may ask: what prevents a malicious server from serving a truly "made-up" authorislation request, allowing a random device to be logged in?
The answer is: nothing!—but the same goes for a server operator overwriting or reading your password as well. All the authorisation discussed here is between you and your server, or, more specifically, for you to prove your identity to your server. If the server decides to ignore that and let other people in too, there's nothing you can do to stop it at this level. That's why we have an added layer of end-to-end encryption, OMEMO keys, and all that jazz.
Incidentally, XEP-0070 (or whatever we develop to replace its interesting half) provides a good opportunity to conduct key signing or identity verification as well. The keys could be generated on your device before it attempts to log in, setting the stage for a more secured handshake above the server-mediated one.
Going a step further, this setup paired with XEP-0450 Automatic Trust Management (ATM) could pave the way for more decentralised logins, where one could log in with different JIDs and different XMPP servers and still be recognised by one's friends (and their XMPP clients) as the same person. But that's venturing into the territory of a whole different topic...
The XEP-0070 hack demonstrates that there is, in fact, a difference between logging in for the first time and logging in every other time. We can use it to log into an XMPP client if we already have other logged-in XMPP client, but surely we cannot claim to have "XMPP clients all the way down"!
So, how would the first XMPP client get authorised? One option is to return a FAST token during in-band registration, so the client can use that as its first connection.
Better still, if we are able to complete registration during SASL negotiation as I speculated about before, the client would automatically be authorised with a FAST token already! Perhaps we can have "XMPP clients all the way down" after all.
We now have a registration system that is not only purely XMPP based, but also entirely passwordless. Before we celebrate though, let's pause to see if we have really covered all our bases.
When online services require a phone number for registration, its purpose is twofold: to prove your specific identity as an individual, but also to prove, within a reasonable level of tolerance, your identity as a member of the human race. In other words, if you are able to receive SMSes through a standard phone number on the telecom network, chances are you're not a robot. This is necessary to prevent spurious signups from automated bots, who can then proceed to send spam messages across the inter XMPP network.
Alas! Our new passwordless mechanism accounts for the first problem but not the second.
Fortunately, this can be readily remedied by making full use of the "extensible" part of extensible IBR. There, we are free to add any other spam-prevention challenges such as additional questions, or if we update the spec accordingly, maybe even a CAPTCHA.
Another way to address this, using mechanisms that already exist, is based on social trust. The idea is to close off public registration and allow signups only using XEP-0401 Ad-hoc Account Invitation Generation. This XEP allows for account invitation links, that any existing user can generate and pass on to a prospective human user. It's up to them to keep the link to humans, of course.
Traditionally, invites open up the old password-based registration screen, but as before we can always skip the password part. Since the XEP allows suggesting a username along with the invitation, it would be possible for new users to be registered, authenticated, and signed in automatically—all by merely clicking on a link!
While this is a nice way to let humans bring other humans into the community, it only scratches the surface of what social trust can do.
It is a truth universally acknowledged, that a person in possession of a good authentication mechanism, will inadvertently lock themselves out with it. In our case, that would mean accidentally uninstalling the last logged-in client, or losing the device onto which it was installed.
This though is no different from doing the same with a password-based account and then forgetting the password. The simple solution is to implement a similar flow based on a second factor like an email or a phone number, which provides a fresh authentication token at the end of it: essentially, a "reset password" flow without the bit at the end where you actually set your password.
To make things more spicy, the Dark Crystal standard allows for account recovery through social trust. The idea is that your recovery information is broken up into pieces, which you can put back together when the time comes. The "social" part is that each piece is given to a different trusted contact for safekeeping.
If you ever get locked out, your account information remains safe with friends—or "in the minds of neighbouring families", if you will.
There is an assumption these days that every person has at least one personal computing device, which they carry with them wherever they go. More often than not, it is assumed that at least one of these devices is connected to the telecom network, which means it is capable of receiving messages via the SMS protocol.
Such assumptions have led to people using SMS and its related phone numbers as a proxy for individual identity, which poses something of a problem in situations where a person does not have a phone number, or where multiple people share the same phone number. Examples include multiple family members sharing the same phone, or a child who has not yet been deemed old enough to receive their own phone. The situation cuts both ways: it is likely that children are reciving their first phone number earlier than before precisely because so many authentication mechanisms require one.
A purely XMPP-based authentication mechanism solves the problem of phone number dependency—but what of the overarching assumption of a separate personal computing device for each person?
Imagine quickly signing into your friend's laptop to check messages, or borrowing a shared account on the family desktop when nobody else is using it. Such interactions used to be common—and are still easily possible—with basic email. On the messaging side, however, end-to-end encryption has made things harder, and a mandatory "sign in using an already-authenticated device" would make it nigh on impossible.
The only way to make this work easily is to use a trusted server, paired with an authentication key that can be carried anywhere and activated on any random device you come across. What fits the bill better than the humble password—which is always with you, right inside your head?
All this goes to show that passwords, though less popular, are far from obsolete—and may never be. However, for those who have trouble with them, there are now feasible alternatives. Thanks to the decentralised nature of XMPP, we don't have to fight between one or the other, rather offering multiple options, the better for each to choose their own.
Thanks to discussions with MSavoritias (fae,ve), Kris, edhelas, and others on the JoinJabber dev room for providing some of the ideas and inspiration behind this article.
