Changing 40+ Passwords: Alarm bells

Previously in this blog series, I looked at the process of changing and remembering 40+ passwords and recounted a few of the annoyances. In this final part, I document a big concern – in some cases changing my password was pointless (well, not quite but almost…)

Question: What do all of the following sites have in common?

• Ancestry.co.uk
• Dropbox
• Costa
• Evernote
• Everytrail
• Facebook
• Flipboard
• Pipedrive
• Premier Inn
• Twitter
• WordPress

Answer: Having changed my password on their Website from Internet Explorer on a Windows PC, I went to my iPad. In each case, the specific iPad app for their site kept me logged on and, able to access all my details – WITHOUT having to enter my newly created password. Read on, it gets worse…

The good news is a whole set of other sites/apps DID recognise my credentials had changed and required me to re-logon. This included Google, Microsoft, Hootsuite, Expedia and eBay. This is important to note, as it shows it is technically possible if the application cares about security.

NB: I doubt the issue is unique to iPads – almost certainly the issue will occur with Android and Windows devices.

What’s the cause of the issue?

It is difficult to be generic, as each case may be subtly different. But in general, in some way, the site is caching some form of token in the app. This may be a session cookie, an OAUTH token or something else – this I do not have a problem with, it provides with a good user experience (as long as I keep access to my device secure with a stronger-than-the-4-digit-default PIN).

The problem would seem to be in the application / authentication server – surely before checking to accept a session cookie or OAUTH token, the application / authentication server should be checking to see if credentials have changed, and if they have force a new logon. This is in effect what Google and Microsoft must have done. So, it seems like poor implementation practice rather than anything else.

(Side Note: OAUTH is not without its security issues.)

Twitter

Twitter is in the list, but they approach it slightly differently. As a user, when logged on to Twitter, I can see which applications I have granted access to, and I could choose to revoke the credentials, forcing a new logon. So, partially acceptable, AS LONG AS I am a knowledgeable user and know I need to revoke access. For fun, I revoked everything in Twitter. This didn’t seem to cause any real issues – re-enabling things as needed works easily and without issue.

Facebook provides some control, but not total as far as I can see.

The big issue…

For the other apps, based on a random sample, I HAVE NOT EXHAUSTIVELY CHECKED, there did not seem to be any way to do this. I could not revoke the existing connections. So for these apps, if anyone steals my iPad, simply changing my application password will not prevent the thief from gaining access to my data. In many cases, it seems there is little I could do to prevent the data theft. This would seem like a big deal to me, and reason for me to review how much I trust the iPad apps on the list above.

I do of course have one mitigation that will help – remote wipe capability of my iPad should it be stolen, but that only partially helps (as remote wipe only works when network connected).

It would seem like we need some standards here. It’s surprising to note some of the sites in my list are presumably PCI-DSS complaint, may be this is where the change needs to come. I welcome reader comments on this.

Concluding the Series.

In this blog series, I followed the advice of the experts, and changed all my passwords following Heartbleed, each password being unique. It was not as easy as expected, with quite a few hurdles, but at the end of the day, largely achievable, so I am in a more secure state than I was.

It would seem that incidents like Heartbleed are on the rise, so we should expect another call to change all passwords in the future. It will be easer next time, but it could be so much easier – if only there were some standards.