19

I'm looking for a way to authenticate users of my mobile app in a secure way. The mobile app is a pure JS app, and is using the ionic framework (and so cordova). The app will only communicate with our server through REST API. Requirements are the following:

  • The mecanism has to rely on a standalone business account (i.e link to Google, Facebook, or any other API is not an option.)
  • The application will be on public stores
  • Like a lot of mobile app (Gmail, Facebook, ...) that doesn't need as much security than bank applications, the user has to be automatically authenticated after a first login ("remember me" pattern)

What I've found:

  • Using of OAuth 2

OAuth 2 provide a long time token called "refresh token". I would like to use it with an expiration date setup to something like one year.

However, it seems that there is no strong mecanism to protect that token. Indeed, as mention in Jamsheed Kamarudeen comment on that answer https://stackoverflow.com/a/7209263/863581, if the refresh token, client id and secret id are stolen (using sniffing or taking them directly from the device), the attacker will be able to have unlimited access to the user account... without any way, AFAIK, to know it's happening.

Sniffing could be difficult because, obviously, all data will be sent through secure connection (SSL), but it's still possible and this has to be managed, from my point of view. Regarding the second kind of attack, "taking them directly from the device", every solution I've seen is about storing data (token or cookie) on either local storage or browser cookie (this post for example Using OAuth2 in HTML5 Web App). Even if the example from that post is advising to store a hash of the refresh token, I can't see what's the aim of that, because, as mention by Mati Cicero's comment, it will not stop the attacker to be able to retrieve an access token and have, in my case, an unlimited access to the user's account.

Moreover, from what I can see, localstorage and cookies are too easy to read. Is that enough or should I use native secure storage of Android/iOS? Even native local storage seems to not be enough (https://github.com/phonegap/phonegap/wiki/Platform-Security).

  • Using of Spring security

The server side will be implemented thanks to Spring. The mecanism provided by Spring-security seems to be better than OAuth 2 regarding the remember me pattern (http://jaspan.com/improved_persistent_login_cookie_best_practice). However, as I have understood, the final user will not be able to login twice on the application (let's say, its personal mobile and its profesional one). I admit it's not a huge issue, but still, it's not perfect. Most important, at the end, we still have storage security issues regarding cookies/tokens.

It's the first time I'm looking for security mecanism, so maybe I've misunderstood some mecanism, please let me know. However, I'm really surprised to see how difficult is it to find the right process. I'm sure it's a classic issue on all mobile applications, but I cannot find any right way to manage that issue.

My question: as you can see above, I don't have found one secure mecanism to setup that "automatic login" process on a web mobile app. What should I setup? Do you have other mecanism than the ones I found to introduce me?

Community
  • 1
  • 1
Sébastien BATEZAT
  • 2,353
  • 26
  • 42
  • 1
    I disagree with the premise that Google login is incompatible with business accounts (ever hear of Google Apps for Work?) or that Gmail and Facebook do not need a lot of security (or that remember me isn't secure), but how to persist credentials on a client is an interesting question. – Michael Aaron Safyan Jul 13 '15 at 09:22
  • I don't have well explained what I had in mind, sorry. Gmail and Facebook do not need as security than bank applications, it's that why you are not auto login on your bank applications but you are on your Gmail and Facebook apps. But you right, these apps need a lot of security. I need to use a business account not linked with Google or whatever other API, it's part of my requirements and not an incompatibily. I will edit my question with that – Sébastien BATEZAT Jul 13 '15 at 09:29
  • Sure they do. Most services reset passwords via an email link. Not to mention that all my passwords are stored in my Google account (e.g. via Chrome Sync). It has to be pretty darn secure. Bad access to Facebook can literally ruin a person's life, including their professional employment. There's a reason that both offer 2-factor authentication via Google Authenticator or SMS (and are arguably, in that respect, way more secure than many of the banking apps that I've used). – Michael Aaron Safyan Jul 13 '15 at 09:39
  • I disagree. How bad access to Facebook could be worst or even equals than bad access to a bank account? And how an application that never ask you to login again like Facebook could be more secure than bank applications, that have very short lived token (few minutes)? If your smartphone is stolen, the guy will be able to access to your FB account, not your bank account (fortunately). If my facebook account is stolen, it's not the end of the world, and most of time damages can be reversed quickly. If I've no more money on my bank account, it's another story.. Anyway, I think it's out of scope – Sébastien BATEZAT Jul 13 '15 at 14:11
  • I think you are forgetting that Facebook is commonly used to authenticate to other applications. For a user whose Facebook account can authorize their note-taking application that they use to store passwords, for example, the Facebook account would be more valuable in that it could grant access not just to the banking information but to practically all other accounts, as well. It is a common misconception that the more annoying your login system is, the more secure it is. The short expiration times are more annoying than effective. – Michael Aaron Safyan Jul 14 '15 at 04:18
  • I'm wondering if any details of this have changed over the last 5 years? For instance, I seems like fingerprint id on mobile phones is the way to go. Every time the app is opened, the user must use their fingerprint, to unlock their stored credentials.. – kodybrown Jun 26 '20 at 14:17
  • AFAIK, things are still the same after 5 years. IMO, thinking fingerprint is a strong security is a mistake. It's an additional security, certainly not a strong one. – Sébastien BATEZAT Jun 26 '20 at 14:23

3 Answers3

5

Remember me consequences

Your desire to have the "remember me" requirement means that (there is no way around it) the client will have some way to have all that's needed to connect to the server and be authenticated.

to OAUTH or not

OAUTH is nice, but if you're not going to trust the common providers, then why do all the overhead ? Just let them pick a password on your site in one go in that case and don;t bother with the back andforth way needed to do OAUTH.

Now that said: why not trust the OAUTH providers ? the user trusted them, otherwise they would not pick them, and likely they'll use the same login and pasword everywhere anyway, so it doesn't really matter.

SSL

Getting the credentials by sniffing out of a properly configured SSL connection: you're way beyond what even the more advanced users like banks worry about. But do configure SSL properly on your server!

A compromise on "remember me" ?

What can you do to enhance the situation:

  • You can void the client's claim it's authenticated if your server notices the browser fingerprint changes, yet the session remains the same. This might happen due to badly configured proxies - but few of those are around anymore. And worst case the user has to log in again.

  • you can use making of IP address to GEO locations (country e.g.) and if you notice a change of country from the last connection without it being a re-authenticated connection: do not honor the remember me and demand a proper authentication.

Protect the cookies

  • You can store cookies in a browser as "secure": it means the browser will only send the cookie to the server if it is on an https connection

  • You can also set a cookie to be httponly: this makes the browser refuse access to the cookie from client side javascript (and all it'll do is send it to the server.

  • You can set both httponly and secure at the same time ... (that's what you want).

  • Thanks for your answer @swa66. Oauth is not a mechanism which compel you to be connected through external providers, I think you misunderstand the goal of Oauth. It's not that I don't trust other providers, sometimes applications need to manage their own account, it's a requirement, that's all. However, I appreciate your suggestions regarding the browser fingerprint changes, and cookies protection. Thanks for your help, it's not answering entirely to my question, but it's a start, +1 for you – Sébastien BATEZAT Jul 20 '15 at 19:40
  • Good suggestion about the IP address and Geolocation! We do something very similar! ... If the IP is the same, continue. If the IP is different, check the location; if the location is a different city, they need to re-auth. – kodybrown Jun 26 '20 at 14:13
2

Whatever the technical solution you'll finally choose, the following stay true :

  • its not about mobile app, all client/server architecture is concerned
  • no manner to persist logins without security risk
  • the more secure way is to encrypt it on device
  • the only better way is the way that bank apps use: no persistance
  • however, two factor sigin is pretty secure too
  • there is no absolute answer to this question, it is just about making the best choice between these considerations and the needs of your app

EDIT

About encryt the credentials

About encryt the credentials, indeed, the code could be read, cause the issue isn't the crypto algorithm, but the private key to use. If you want to encrypt credentials, you have to implement an UI that permit the user to set a shema or pin code or any else secret to transform in private key to encrypt then decrypt the user credentials.

But if the user lost its pin, you need to generate new credentials server-side to reset server-password then reset client-secret client side.

Rémi Becheras
  • 14,902
  • 14
  • 51
  • 81
  • It's not just about mobile app, but the fact it's a mobile app is creating more security concerns (it's easier to steal a phone, not possible to rely on user's IP address, no strong security - AFAIK - on data storage ...) and different usages (it's better to persist login). I'm not asking for a "without security risk" mecanism, I'm asking for the standard way to setup these kind of stuff, with the best security mecanism. "The more secure way is to encrypt" => what are you advice regarding that, knowing it's easy to see source code of the app and have a look at the encryption mecanism? – Sébastien BATEZAT Jul 15 '15 at 20:34
  • Regarding your last sentence "there is no absolute answer to this question". False, there is, and "it is just about making the best choice between these considerations and the needs of your app". It's what I'm looking for. If you need more info about that, please ask. – Sébastien BATEZAT Jul 15 '15 at 20:35
  • It's a while web apps works on laptop though, and laptops are often stolen, with often zero security on boot.. Maybe I'm wrong but if you ask the question, how can you affirm that "false, there is [an absolute answer to this question]" ? Yes I understood that your are trying to make the best choice with considerations, I just tried to explain that its always the case, for each case we have to make this choice. – Rémi Becheras Jul 16 '15 at 07:06
  • I'm sure there is an absolute answer (even "not possible" but I don't think it's the case) because this is an absolute question. If you think the question is not described enough regarding my considerations, please ask for more details, but for now, you definitly not answering the question. You'll answer to that question as soon as you will explain what's the best choice for me. Thanks to try anyway. – Sébastien BATEZAT Jul 20 '15 at 19:30
0

One way to do is, you can store the private key and token encrypted, then the question will be, where to store the key. For that, if you are using cordova, you can simply make a plugin for cordova and store the keys there. At the start of the app, you can make a call to cordova to fetch the keys. Since the plugin is in native part, it will be compiled so it will give you more security.

MJ Fathinia
  • 259
  • 2
  • 11
  • Thanks for your answer but, as said on the question: "Moreover, from what I can see, localstorage and cookies are too easy to read. Is that enough or should I use native secure storage of Android/iOS? Even native local storage seems to not be enough (https://github.com/phonegap/phonegap/wiki/Platform-Security)." – Sébastien BATEZAT Jul 24 '15 at 14:46