Share My Creation Password-free login to a secure site

This isn't a complete project - just a part of one, but I thought it worth sharing, both because it might inspire others and people might spot a security flaw I've missed.

Background: the site I run is a social network, and we also have apps built in B4X, which talk to the system via an API built around JSON data posted to an endpoint encrypted using TLS. I often have problems with users who've forgotten passwords - especially if they tend to use the app. When the app is set up, it asks for permission to use your account, and once that's done, it doesn't ask for anything more (a bit like oAuth, but less convoluted). You can, if you want, tell the app to request a PIN or biometric id when it starts.

So, since people tend to carry their phones, on which they can easily authorise themselves in a number of ways, and forget passwords, I wanted to find a way people could sign in to the site without a password, while still maintaining security. This is the result.

The user goes to the site, and in the login box, they just type their email address, and click the 'Login with the app' button. A notification is sent to their mobile device, listing details about the login request, and a progress update is displayed in the browser. If the request is confirmed on the mobile device, then the login is completed in the browser.

How it works:

1. On the website, when the user's email address is entered, a temporary session id is created and stored in the database, along with a status.
2. A Firebase cloud message is sent to the user's topic, indicating that there's a login request. This may go to numerous devices, so contains no secret data
3. The user's app authenticates itself with the API, and requests details of the login attempt.
4. Geolocation (from the IP address) and browser info are returned, together with the temporary session id, encrypted with the member's public key
5. The app presents the information and asks the user to allow or deny the request
6. The temporary session id is decrypted by the app, and then re-encrypted using the server's public key, and returned alongside the decision on the login
7. The API server decrypts the received session id, and if there's a temporary session with that it, for the member associated with the app, then the status in the temporary session table is updated to allow login

Meanwhile, the login page that's displayed in the user's browser refreshes every few seconds; as it does the database is queried for the temporary session key and its status, so the user will see messages like "Attempting to contact your mobile device" or the one shown in the screenshot, with browser and IP information. If there's no response within three minutes, the status is changed to "timeout"

However, if the page reloads and the status is set to "authorised" in the database, then the normal session startup procedures for the website are run, and the user's directed to their post-login landing page.

I'm going to allow only one device per user to be configured to work this way, but I think it'll make it simple for a lot of people to log on without remembering passwords. I may perhaps restrict the functionality to those who have put a PIN or biometrics on their app startup, too.

All the communications happen over TLS, nothing is sent via a GET request that could hang around in logs anywhere, and the key bit of data, the temporary session id, is always encrypted for transfer.

Any feedback is welcome; I can post some of the code snippets too, I guess.

 

[Hamied Abou Hulaikah]

2. A Firebase cloud message is sent to the user's topic, indicating that there's a login request. This may go to numerous devices, so contains no secret data

feedback: I created many apps that was depend on Firebase notification, it will not work all time 100%, so you should think in another replacement of firebase notification!

 

[nwhitfield]

Well, if you're relying on another channel for notifications, it's hard to find something totally reliable. Even texts can go astray.

But people can still use a password to login if they don't get the firebase notification in time

 

[techknight]

I think when someone initially installs the app, they need to login with their password at first. Then, it generates a unique ID/hash on your server, from device specific data and account information. and this response which sends back and gets stored in the "app's" private storage. This will allow device authentication having multiple devices on 1 account, and say, one device gets out of someones hand, or in a hackers hand, that device can be deactivated, requiring a password to enter again.

First time logins could simply be a password and username, or, Apple/Google login, etc...

 

[nwhitfield]

That's essentially what they do - the app asks them to login to the site in a webview, and the site then says "Do you want to grant this device access to your account?"
I could relatively easily allow multiple devices to be used to authenticate logins, but most people tend to have only one primary device, so I'd just be complicating the code largely to handle a few edge cases like me who have a whole pile of phones on their desk. And since it's to do with security, I'm in favour of keeping things as restrictive as possible.

Re things like Apple/Google login, because of the nature of the site, we don't even have Google analytics on it, or use CDNs for things like fonts. We aim to minimise the amount of data leaked as much as possible, so that rules out using third party login services. And even if I were minded to use them, my own experience on the mac with AppleID has been so flaky - especially since updating from Snow Leopard to the more recent builds - that I'd only inflict any Apple identity service on people if I was feeling extremely sadistic. Having been a daily Mac user since the 1990s - and it's still my main system - I'm more and more disenchanted by the quality of their produts.

 

[techknight]

Kind of a strong assumption there. I have like 3 main devices. and a couple spares. I do have a single/primary phone which is a work phone, but I dont use it as my primary computing device. I only use it to call, text, and check my gmail once in awhile. I still do all my computing on PCs.

But I digress...

 

[nwhitfield]

Not a massive assumption, but based on the data - since each device has to be linked to the account, I can see exactly how many people have multiple devices, and if they're still used. Most people have one phone at a time, and that's it. Pretty much by definition, the people posting here are outliers, and quite far removed from "ordinary" users. A smattering of people have iPads as well as phones, but that's all it is - just 30 iPads registered out of a site membership of over 4000; not even three quarters of 1%

Frankly, many users can't even answer questions like "What browser are you using?" when they report a bug on the website (well, not so much as bug as a really unhelpful "The website doesn't work" with no further details). Although I'm slowly trying to push them towards using more security (we already support Authenticator, Yubikeys and U2F, as well as grading passwords when they're created, and blocking the most common ones), even on a site where people talk about very personal stuff, it's surprisingly hard to get some people to take security seriously.

If it turns out that suddenly lots of people realise using a device as a second factor is easy, and they want support for multiple devices to do it, then I can add that later. I just don't think, based on what I know of the user, that there's going to be a pressing need multiple device support any time soon.

 

[Diceman]

What happens if the person's phone is stolen? Or absconded by a "friend" or roommate?

 

[nwhitfield]

First, we'll be recommending (or I may even make it mandatory - still pondering that) that people have biometric authentication turned on in the app to use this function.

Second, the website has a mechanism for the user to sign in and de-authorise devices that have been linked to their account (or, for the more bewildered, admins can do that for them if necessary; we use old fashioned security Q&A to verify their identity in that case).

So, we have that covered to the extent that it's possible to do so. I would hope that, since members have to authorise the app against their account to use it, they're at least aware that that is an actual thing that it may be possible to reverse. I doubt, for example, that many casual users are aware that on Facebook they can go to Settings / Security and Log in, and sign out a device that may have been stolen.

If we enforce biometrics when the app launches, that will probably address most common issues. I don't know of any research into how people have their devices locked, but don't you need some device security set up if you've enabled Apple or Google Pay?

If I don't enforce biometrics, it's theoretically possible that someone who has no screen lock on their phone, and no PIN or biometrics enabled in our app might leave their device lying around, or have it stolen, allowing the new owner to sign in to the app and, umm, tinker with their social profile. If they've enabled the "Login with the app" function, then if that person knows the email address that's used to sign in to our website, then they could potentially log in using the app, and it's possible to be a little more destructive on the website, eg deleting an account completely, than it is via the app.

So, I am tending towards requiring having some of the app security turned on to use this feature - but if someone has a completely unprotected device then there are likely far bigger concerns for them should it be taken by someone.

Ultimately, I think the thing that we all should be trying to do is to find ways that we can secure our websites and apps, and provide as many safeguards as we can, while still reducing the amount of friction for users. This is just one way of doing that, and I think for a lot of users it beats remembering a password, while still offering pretty good security by requiring the device/app as a second factor.

If you want an example of unnecessary friction which achieves pretty much nothing, I have two factor enabled for my PayPal accounts, and on the Android app, I have fingerprint login enabled. But even after asking for my fingerprint, I still get asked for a second factor, which involves either switching to the Authenticator app on the same device and copying the code, or getting a text message sent to the same device, and copying the code. Practically speaking, that adds nothing to the security of that device, except an irritating extra step.

 

[tex22]

I'd prefer a Telegram bot instead Firebase. Telegram has two step verification and local passcode. Shielded against "friends", roommates and thieves.

 

[nwhitfield]

I'd prefer a Telegram bot instead Firebase. Telegram has two step verification and local passcode. Shielded against "friends", roommates and thieves.

That's going to require people to sign up for Telegram as well, though, isn't it? So while it might get a little traction amongst the hard core techies, I can't see many ordinary users going for that. Using Firebase to trigger the system means that all they need is our app, nothing else.

Also, remember the only thing we use Firebase for is an initial trigger - the payload of the message is pretty much just

array ('sendername' => 'BLUF login request', 'action' => 'loginrequest', 'fulltext' => 'Confirm a request to log in to your BLUF account') ;

When the notification is parsed, and the loginrequest action is spotted, then the app logs in automatically over TLS, and starts the negotiations with the server to get details of the request. We could potentially use SMS to send the trigger, but of course that requires us to store user mobile numbers, and isn't free to use.

 

[Diceman]

First, we'll be recommending (or I may even make it mandatory - still pondering that) that people have biometric authentication turned on in the app to use this function.

Second, the website has a mechanism for the user to sign in and de-authorise devices that have been linked to their account (or, for the more bewildered, admins can do that for them if necessary; we use old fashioned security Q&A to verify their identity in that case).

Good idea. I never thought of that. Of course like you said it will require Q&A to prevent someone who stole the phone from doing the same thing to the user.

So, I am tending towards requiring having some of the app security turned on to use this feature - but if someone has a completely unprotected device then there are likely far bigger concerns for them should it be taken by someone.

I hear you. I'm still waiting for my Bitcoin from Jeff Bezos. Last month he promised me he would double my Bitcoin if I sent him some. I'm still waiting. I never did trust that guy. Very shifty eyes. If I don't hear from him this month I will lodge a complaint with Amazon and I don't want any free merch from him. I want my BTC back! ?

Ultimately, I think the thing that we all should be trying to do is to find ways that we can secure our websites and apps, and provide as many safeguards as we can, while still reducing the amount of friction for users. This is just one way of doing that, and I think for a lot of users it beats remembering a password, while still offering pretty good security by requiring the device/app as a second factor.

Agreed. Some apps I use will force a pw to be entered if it hasn't been used in over 'x' hours.

If you want an example of unnecessary friction which achieves pretty much nothing, I have two factor enabled for my PayPal accounts, and on the Android app, I have fingerprint login enabled. But even after asking for my fingerprint, I still get asked for a second factor, which involves either switching to the Authenticator app on the same device and copying the code, or getting a text message sent to the same device, and copying the code. Practically speaking, that adds nothing to the security of that device, except an irritating extra step.

The 2FA is used to protect the website from being hacked, not the app on the phone. All financial sites demand 2FA which is more secure than SMS. A lot of crypto exchanges had accts hacked a few years ago that did not use 2FA but had SMS enabled. The hackers were very good. The level of security all depends what you are protecting which determines the skill of the hacker that will attempt to breech it.

I will use some of your ideas to implement better security. I will have stricter levels of security implemented in the app code and server code but these security levels won't be activated unless there is a security breech on the server (or admin access), in which case I can contact the server to force stronger security like 2FA on specific users or all users etc..

 

[rraswisak]

Thank you for sharing and the idea, it also good to be implemented on authorization system (not only in login page) but some thing like approval from superior when he/she not on the desk (mobile) and need approval immediately

 

[nwhitfield]

Thank you for sharing and the idea, it also good to be implemented on authorization system (not only in login page) but some thing like approval from superior when he/she not on the desk (mobile) and need approval immediately

Yes, I'm actually thinking of extending it to some of the other situations on the site too. We have an option we call 'profile protection' which members can turn on, which requires that they re-authenticate themselves before doing certain actions, like deleting photos, or updating profile text. I'm sure everyone's seen those "funny" posts where someone's picked up a friend's phone or walked up to their PC when they're not looking and posted a stupid Facebook update on their account; it's intended to stop that sort of thing.

So, that will probably be the next part of the site to have this added. In fact, for that it may be even more helpful to members. If someone thinks they'll mess up your profile at the moment, you won't know that they tried and failed, because they could just close the pop-up "You aren't authorised" box on the web site, but with this, there'll be a notification on the phone.

We also have certain members who have enhanced privileges for admin, which presently require mandatory two-factor ID via Authenticator, Yubikey or U2F, and I will probably add this as an option.

(Side-bar: even with people on whom you have impressed the need for privacy and security, and trust to help with admin tasks, there was a surprising amount of push-back when I made using two-factor mandatory for accessing all admin functions, and I had to write a step by step guide to how to set up Authy, which is our preferred authentication app, to help people do it. So that's another area where I'll use a version of this, with the 'action' element of the original data packet set to indicate what sort of thing has to be approved).