Skip to main content

Storing login information on the mobile web

By Jason Grigsby

Published on March 22nd, 2013

Topics

One of the big advantages that native apps have over mobile web sites is that native apps never ask you to login again and web sites do. Why is that?

Let’s look at a very specific example of a site and app that I use on a regular basis—the Alaska Airlines app and mobile site.

Because I travel a fair amount, I have found myself using both Alaska Airline’s iOS app and their mobile web site quite a bit.

I end up using both because neither does exactly what I need. The mobile web site will tell me where I am on the upgrade waitlist, but the app won’t. And while the app doesn’t have all the data I need, it doesn’t log me out which means I don’t have to dig up my password to find any of the information that the app provides.

Login screen on Alaska Airline’s mobile web site. A screen I see far too often

I would prefer to use the mobile web site. There are a few things that I like better about the mobile web site than the app and I get some data, like the upgrade list, that I don’t have in the app.

Despite my inclination, I find myself using the app more often because I don’t have to worry about supplying a password.

Which brings me to my question: why do I need to continually log into the mobile web site and not the app?

There is nothing that prevents a website from keeping me logged in indefinitely. If it is for security reasons, then wouldn’t those same security reasons apply for the native app?

I’m honestly confused by this. It isn’t just Alaska Airlines that I see making different decisions about how long they store credentials in apps versus mobile web sites. Does anyone have a good reason why this might be the case?

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Comments

Guypo said:

Good point, but I think the security model is different due to Cross-Site Request Forgery. Attackers can make your browser send a request to domain A while browsing domain B, without your knowledge/consent and with your cookies. If you’re logged in, they can trigger actions on your behalf.

There are ways to defend against it, but they’re not trivial, thus the best practice is not to remain logged in (minimizing damage).

Apps are not susceptible to the same threat.

Permalink to Guypo’s comment

Replies to Guypo

Jason Grigsby (Article Author ) replied:

Same issues with localStorage instead of cookies?

Permalink to Jason Grigsby’s reply
Replies to Jason Grigsby
Guypo replied:

Using localStorage is not safer if its automatic. For example, if there’s a stub page that loads the login credentials from localStorage and logs in, it can be loaded in a hidden iframe.

Still, You can try and detect if you’re in an iframe or use localStorage to auto populate a manual form, or do various other things to make you secure. My point is not that you CAN’T keep the user logged in and still be secure, but rather that it’s HARDER. Apps make some of the risks go away, which (in part) leads to the norms that we currently have.

I think your next great blog post could be one outlining a secure ‘remember me’ mechanism for mobile websites for people to mimic 🙂

Sorry for the late reply, btw, for some reason I didn’t get notified you replied to my note.

Sérgio Lopes replied:

Small cookie expiration doesn’t protect you against CSRF. You lower the chance, sure, but it’s not a protection, it’s simply probability and you’re still vulnerable. To protect against CSRF, you should generate those unique request CSRF tokens.

I don’t see any security implication in remaining logged in all the time on the browser. If, of course, your webapp is done right.

Tomislav Car said:

From a security standpoint, I’d say you’re right, and there’s no major downside in security, comparing native apps to web apps.

A website can’t steal another websites cookies, although you could probably fabricate some bizzarro-world phishing scenarios.

The problem you’re having could be related to the issues with the “Remember cookies” setting for Mobile safari which has been known to act iffy at times.

Jeremy Chatfield said:

CSRF & some ways to protect against it are covered here – Open Web Application Security Project. I think that’s good stuff, but I haven’t worked in Info Sec for a decade. 🙂

There’s probably another issue that Alaska Airlines are intending to protect you from, which is that browsers may be on publicly accessible devices. If you were in an internet cafe using a shared computer, then clearing your access is appropriate, to protect you from other people wandering in after you leave and using your account. You can see some websites offer “remember me on this device” checkboxes during signin, so that genuinely-personal personal computers can retain authentication for longer (days, months even).

Jeff said:

I think the “security” issue is a much simpler one. Wouldn’t a phone or tablet be far more susceptible to loss or theft? Hence storing passwords opens up a whole new arena for potential fraud? Throw in our tendency to share (read: hand off without thinking) these devices with friends, children, and others and now that security risk increases. Our traditional desktop devices are seldom shared and also have the ability to have user accounts, hence alleviating some of this concern. Just a thought, not a concrete answer by any means. A stored login would certainly be a better UX, but probably not a safer one.

janwillem kluivers said:

Isn’t this a “monkey turns the wheel” implementation. Websites, by history, are considered stateless, impersonal and used anywere on any device. App’s are considered personal, on your personal device and used “in a hurry/ on the move” (I know this isn’t the case…)

Or, i suppose the folks at Alaska might be delighted if you use their well crafted app and therefore they give you a bonus, log in once, use multiple times.

Last, what if the site is designed by a sub team of, or overseen by, desktop department and thus policies. Is there a auto-logoff on their regular .com as well? If they use your CC details my guess would be there is…

To wrap it up, i’m not sure if this is a technical issue. Even though HTML 5 storage doesn’t seem to be safe….

Just my 5 cents.

KatyO said:

my 2 cents as an app product manager on the experience deltas.

Alaska wants you to login to see your private information in the browser. They don’t want to futz with the security hurdles and/or perception of security hurdles to the average joe-on-the-street. good or bad, the consumer expectation is that w/in a browser you log in first before accessing private data.

Whereas the joe-average perception of apps is that they operate on a personal device and are more private. Therefore once a user has logged in, he has established his identity and he expects it to be saved it within the app. Alaska treats app users consumers as semi-credentialed; users can view flights/etc. BUT, when it comes time to purchase, the app re-prompts for a login before accessing any stored payment devices. The app isn’t a complete free-for-all; it’s just masquerading as one until the user tries to do any real ‘damage’.

Now, as far as features, I bet that’s just organizational stupidity. 2 common scenarios I’ve personally experienced: 1) new features are rolled out on one platform first. If they are used & reviewed well, they are migrated to additional platforms. or 2) the app team & mobile web team are under separate reporting groups and they don’t talk or share feature roadmaps.

Bruijnesteijn said:

Some pointed out the risk of using the website from a public device. Others replied that the website can determine whether the requests comes from a mobile device or another device. The risk exists and yes, the website can recognize the device using the user agent. However it’s pretty easy to fool the website by manipulating the user agent and pretend to be mobile device (check your developer possibilities in Firefox and Safari to set the user agent). So it’s possible to manipulate any public device running a browser and make it look like a mobile device.

The difference lies more in the fact that a mobile device is considered ‘personal’ and ‘not shared’. So access to local information is less a problem and the responsibility of the owner. Just like setting a passcode lock for your phone which is also possible for your own computer, but not possible for public accessible devices. From a security point of view I wouldn’t accept the login status in the mobile device to allow access to very confidential data, maybe you will allow the app to get airline reservation data, but I would be reluctant to expose personal account data or payment preferences.

So therefore I think there is a difference between apps and websites.

So I think one should be careful to think it’s either ‘keep me logged in’ or ‘always expire after an amount of time’, you may have for convenience ‘keep me logged in’ on the mobile device for some functions and still ask for the cerdentials again for some transactions.

Of course the app should store the credentials secure and encrypted, never show the password in readable format.