On Passwords Protocols and Publicity

I recently went through the process of relocating my DSL service (I know I know – it’s not cable or NBN, but hey, I barely use it!) Two days after my seemingly flawless account update, I received a text message on my phone, and thus begins my rant on passwords, protocols and publicity.

My story begins when I received my new account password by SMS, along with my username, and the provisioning date. To a mildly security conscious individual such as myself, this raised an eyebrow to say the least.

This isn’t the first time this has happened. I encountered this same information exposure 12 months ago. I pre-emptively updated my account and connected to my internet service between provisioning and head office’s batch jobs emailing me my confirmation.

So as I oft’ do, went straight to twitter to seek clarification!

The problem is the packets

I’m not a hardcore network security engineer, though I had planned an ISP call in the morning to pursue the case further to raise my concerns. Luckily for me someone who is ever slightly better informed on these matters than I was kind enough to respond – thanks Ben!

Brilliant, turns out that the plaintext password is required from a networking level – nothing to do with the application or database at all (so there goes any theory of application wrongdoing right!?)

PPP section 2.2.1 states that my password is required to be sent in the initial authentication packet. Gotta love network engineers from 1992 right? Not even the updated RFC 4 years later properly addressed this! ACK!?

Publicity & Perception

I’ll not name and shame my ISP on blog. I was, however, replied to with a “We have no plans to address your concerns but you can escalate to a manager on $phone”. Might just do that to see how it goes. But high-horses aside, I asked myself “What can be gained from this experience, instead?”

Firstly it serves as an excellent reminder to all application developers – we need to consider the ‘perceived security’. The SMS in this instance included my username AND password. Considering how SMS’s are usually consumed raises the following points:

Default phone behaviour is to show message contents in notifications, even on lock screens.

3rd party services can be used to transform mobile notifications into desktop alerts (e.g. PushBullet etc.) What if I had been teaching a lecture full of networking students!

If you’re building for customers, think like your customers and how they consume and engage with your content. People inevitably behave in unexpected ways that can lead to accidental security breaches. Often, your customers will be your weakest link when it comes to security!

Second to this is the perception of security. Many consumers are becoming increasingly aware of password security, and I’m sure that sending a plaintext password (one that’s been on file for a while mind you) would raise a few eyebrows. Even if the ISP application stores them in a reversible format (let’s not delve into encryption strategies just now), does it make sense to expose this fact to your consumer? Furthermore, do you respond on social media with “We have no plans to address these concerns at this time”? I could rant further but I won’t, so for brevity I simply ask you question how your application security is perceived by your customers.

I’m not content, however, just ‘accepting’ this, I’d like to know what we can do to fix it! I might not be a IETF member writing revisions to network/packet protocol RFC’s, but I can suggest alternatives right?

In researching the PPPA RFC I note that the plaintext password is only required between my point of presence (i.e. modem) and the remote point (i.e. my ISP). So it’s just a token, a code, an access key that’s assigned to me, right? Why, then, can we not separate account credentials from network access codes or tokens? Can an ISP provide me an opt in configuration to rotate my network key or code and let the techi-heads self manage their security concerns? The benefit here is that PPPA password is known only to the network and if intercepted cannot be used as an attack vector against my personal account (that’s an account that has both my financial and PII data by the way!).

Note: For my own sanity I decided not to introduce a discussion of MFA or other authentication methods into this rant.

If this rant happens by the ears of someone who agrees, I’d love to hear from you! It would be awesome to put together a hardware hack to demonstrate a fix.

Special Thanks

I’d also like to thank Ben Dechrai, Yinette and a third friend (who requested to remain anonymous) for their reviews, contributions and time spent listening to my rants.

developerjack

Add comment

You may also like

It’s become somewhat of a tradition to do a PHP version round up at the end of the year. In 2014 Anthony Ferrara posted PHP versions in the wild and last year I continued the tradition (with his blessings) with my PHP...

This is a quick code dump post to share a script for automating LetsEncrypt certificate renewals for my blog! What is LetsEncrypt? LetsEncrypt is a certificate authority who’s goal is to provide free certificates to...

Last year, Anthony Ferrara posted an excellent round up of PHP versions in the wild, specifically focusing on the volume of un-patched versions running production websites. Even as an estimate it was an eyeopening...