Author Archives: Troy Hunt

Humans are Bad at URLs and Fonts Don’t Matter

Humans are Bad at URLs and Fonts Don’t Matter

Been a lot of "victim blaming" going on these last few days. The victim, through no fault of their own, has been the target of numerous angry tweets designed to ridicule their role in internet security and suggest they are incapable of performing their duty. Here's where it all started:

Let me include a screen grab of the poll NordVPN posted in that tweet because for reasons that will become apparent in a moment, your experience may differ:

Humans are Bad at URLs and Fonts Don’t Matter

When I first saw this poll, it had already ended so the votes were on full display. I assumed Baidu got the lion's share of the votes by virtue of the HTTP address not being served over the secure scheme, even though HTTPS has got absolutely nothing to do with the trustworthiness of the contents of a website. If I'm completely honest, I had no idea what the correct answer would be because frankly, I'm bad at reading URLs. Turns out it was the third one:

Ah, tricky! Everything becomes clear(er) if I manually change the font in the browser dev tools to a serif version:

Humans are Bad at URLs and Fonts Don’t Matter

The victim I was referring to in the opening of this blog post? The poor old sans-serif font with multiple people throwing it under the proverbial bus as a useless typographic choice for expressing domain names. I'm going to come to the defence of the simple typeface in this blog, starting with an explanation of what we're actually seeing here - homoglyphs:

In orthography and typography, a homoglyph is one of two or more graphemes, characters, or glyphs with shapes that appear identical or very similar.

But the characters in NordVPN's poll only appear similar because the case is being mixed, so why not just lowercase everything? That's what happens already once the URL appears in the browser's address bar:

For the domain NordVPN used in the poll, let's have a look at how it renders in the browser (oddly, the site doesn't support HTTPS so I've changed the scheme, but the domain name is the same):

Humans are Bad at URLs and Fonts Don’t Matter

Turns out that googie.com isn't a phishing website, rather it's a legit real estate services business, shown here in Chrome at the very common resolution of 1080p. Can you spot the subtle difference in the domain name compared to the search engine? Can you clearly see how the "i" is not an "l"? Obviously, the image is resized to the width of paragraphs on this blog, give it a click if you want to check it out at 1:1 size. But let's also keep some perspective here; look at how many pixels are different between an "i" and an "l":

Humans are Bad at URLs and Fonts Don’t Matter

Are we really saying we're going to combat phishing by relying on untrained eyes to spot 6 pixels being off in a screen of more than 2 million of them?! Of course not, especially if someone has just arrived at this page after clicking on a link like NordVPN's with the uppercase "I" and especially not if instead of a "fine real estate" website the page was a phish designed to look precisely like Google. Bartek's suggestion was entirely understandable, but also entirely unreliable.

Much of this comes back to the old chestnut about how involved users should be in the whole decision-making process around the trustworthiness of a URL and indeed, how proactive technology should be to help them with this task. For example:

So... someone wants to look for some fine real estate on googie.com and the browser pops a warning? Poor Googie! Just having a similar name doesn't make a site "bad" (or potentially bad) in just the same way as not having a similar name doesn't mean the URL isn't pointing at a phishing site. More on that soon.

But there's another problem too and it boils down to the fact that homoglyphs are a much broader issue than a couple of characters in sans-serif appearing similar. For example, the Wikipedia article on the topic demonstrates how the first letter of our Latin alphabet expressed in lowercase is indistinguishable from a Cyrillic version when expressed in the Helvetica font:

Humans are Bad at URLs and Fonts Don’t Matter

The blue in-fill is the familiar "a" whilst the red outline is the Cyrillic one and whilst these two characters look the same, they're actually totally different. Consequently, you could feasibly have two different URLs expressed that whilst visually identical, actually go to different places. Here's a beautiful illustration of the problem:

Humans are Bad at URLs and Fonts Don’t Matter

If you look at the address bar in the current version of Firefox, your eyes tell you you're looking at apple.com yet if you look at the title of the tab, you realise you're not on the tech giant's website at all rather you're on аррӏе.com instead. Huh?!

Now let's get really messed up and inspect the paragraph above in Firefox's dev tools:

Humans are Bad at URLs and Fonts Don’t Matter

The browser shows the company name we all recognise on the page and just under the mouse we see the same name again in the status bar. Yet in the dev tools we see the href attribute of the hyperlink referring to an unrecognisable string of characters and the domain name within the <a> tag almost looking like a very familiar one, albeit for the fourth character. Click the link on Firefox and you end up on a page talking about IDN homographs but if you're on Chrome, the experience is different; it still looks like the tech company's domain in the browser but hovering over the link shows the href value from above in the status bar. Actually clicking the link then gives you this:

Humans are Bad at URLs and Fonts Don’t Matter

This is a demonstration from April 2017 of phishing with Unicode domains:

Visually, the two domains are indistinguishable due to the font used by Chrome and Firefox. As a result, it becomes impossible to identify the site as fraudulent without carefully inspecting the site's URL or SSL certificate

You can delve into the details of how this works in the link above but for now, there's two important messages to take away with you:

  1. Even careful visual inspection of the URL is insufficient to determine the actual website address you're visiting
  2. Different clients can render precisely the same URL in completely different ways

This is why sentiments such as this are so misplaced:

This is not a "sin" committed by either typographers or coders and blaming the poor old sans-serif font merely makes it the victim in all of this. It's a misplaced sentiment as we simply have similar looking characters in different alphabets. Is it any wonder that people are bad at reading and understanding even the domain part of the URL then making decisions based on that which affect their security and privacy?

What if we took a different tack? I mean what if we somehow made it much clearer to people the actual URL they're on in a way that isn't ambiguous due to the characters used in the address? Be more "user-centric", as it were:

Let's tackle why this doesn't get us any closer to a real solution and this is where things gets worse - much worse. Before you start watching the video I've embedded below, let me set some context: this talk is by Emily Schechter who works on the Google Chrome team. I saw her deliver this keynote at LocoMocoSec in Hawaii a couple of years ago and it really resonated with me. Emily is one of the best in the business with more access to real world information on how people interact with browsers than just about anyone, so listen to her words carefully (I've deep-linked to the relevant section, just give it one minute of your time):

Do you think you can understand just from the URL who's publishing these sites? Can you tell which one of these is the real Google blog site?

Humans are Bad at URLs and Fonts Don’t Matter

I can't, because as we've already established, I'm bad at reading and understanding even the domain part of the URL, just like you are. In case you were wondering, the real Google blog website is at blog.google and the only way I know that is because I fast forwarded to the 16 minute mark of the video and heard Emily say that! The point I'm obviously making here is that when we talk about people being bad at interpreting URLs, it's not a problem that's solved simply by changing the font or "centring their experience", the issue is so much deeper than that.

But none of that stopped the Twitter peanut gallery from chiming in on their displeasure about difficulties that URLs pose. Some suggestions were reasonable, others were, well:

A common theme amongst the responses on Twitter was about user-centricity, empathy and accessibility. These are all good sentiments, but as I said in a follow-up tweet, they're all motherhood statements that carry nothing of substance. It's akin to saying "we should solve world hunger" then wandering off without actually providing any solutions. Or saying something like we should just have a "funded multi-disciplinary team" and that'll solve the probl... ah:

I'm sure it'd be very nice to have this team, but what are they actually going to build? Is it a button? A notification somewhere? This isn't a solution to phishing, it's suggesting that there should be a team of people who can find solutions to phishing, kinda like the Google Chrome team, right? 🙂

A suggestion that was more practical in nature involved displaying some form of verified identity on the site:

Whilst this sounds good in theory, as Bartek observed, browsers don't do that anymore and for good reason: it never worked in the first place. It never worked for all the sorts of reasons I outlined in that blog post and the others that preceded it. At the very heart of EV's failure was this simple false premise: that on a per website basis, users are able to use their own judgement to accurately make a trust decision based on the absence of a little-known (and rarely present) visual indicator. They couldn't, just as they can't with URL parameters, fonts with or without serifs and indeed even entire URLs without any obfuscation whatsoever. It. Just. Doesn't. Work.

But what if they could? I mean what if the world was completely different to what it actually is and people understood visual security indicators? Not just visual indicators, what if people could actually read and understand URLs?

Clearly, they can't at present (we've already established that), so what would be the challenges in changing this behaviour?

Scott nailed it here - changing the status quo across billions of internet users simply isn't feasible and any solution that requires them to detect subtle nuances in the structure of a URL is bound to fail. There are places where visual indicators can be very effective, but we're talking really obnoxious ones such as Chrome's warning above on the punycode Apple domain. That's a very different kettle of phish (sorry, couldn't help myself!) to suggesting that we can train people to read and understand URLs.

So, can we just take the humans out of the picture and instead identify phishing sites with the technology? We can already and last month I wrote about how NordVPN's CyberSec can block this sort of thing outright:

Humans are Bad at URLs and Fonts Don’t Matter

Per that blog post, this was a legitimate phishing site (ok, I used the word "legitimate" in an odd fashion here but you know what I mean 🙂), and check out the URL; none of the prior suggestions around using a serif font stop sites like this. Does anyone honestly think less people would fall for it if the font was more decorative?!

Before wrapping up this post, it's worth touching on why we have sans-serif fonts in places like Twitter clients. In fact, let's first acknowledge that unless someone can prove me wrong, every Twitter client uses a sans-serif font. Certainly, the Twitter website does, so does the native iOS client and so does Tweetbot. If you're using a client that doesn't, I'd love to know about it. Now, do you think it's just coincidence that things worked out that way? Are coders "sinners" for building the clients using these fonts or might there actually be a legitimate reason why? Of course it's the latter:

Sans-serif fonts tend to have less stroke width variation than serif fonts. They are often used to convey simplicity and modernity or minimalism. Sans-serif fonts have become the most prevalent for display of text on computer screens. On lower-resolution digital displays, fine details like serifs may disappear or appear too large.

That said, I've obviously taken a different approach with this blog but I'm also not trying to condense as much information into a small space as what Twitter is. Regardless, a sans-serif font is no more a "sin" than a serif font would stop phishing so no, I can't see Twitter clients changing tact and it would make very little difference anyway.

So, what's the answer? I mean the actual solution rather than just, say, recontextualising killer networks. (Ok, so I took that from the bullshit generator but it's indistinguishable from some of suggestions referenced earlier.) Turns out we do have solutions and as several people pointed out, using a decent password manager is one of them:

Want to make a meaningful difference to phishing attacks? Stop whinging about fonts and instead get people using an up to date browser that flags known phishing sites running through NordVPN with CyberSec turned on and authenticating to websites using 1Password. Keep educating people, by all means, but expect even the savviest internet users will ultimately be as bad at reading URLs as I am 🙂

Weekly Update 214

Weekly Update 214

It's a very tired weekly update as I struggle a little bit after only a few hours' sleep but hey, at least I've got a nice haircut! In more topical news, I'm pretty happy about the experience installing Ubiquiti's AmpliFi ALIEN gear into a neighbour's house, it's Trump on top of Trump with his password commentary and then his actual password and finally, questions from the audience on AmpliFi versus UniFi which some people might find interesting. Next week, I'm hoping I'll be able to talk about the Ubiquiti doorbell as well so tune back in for that one.

Weekly Update 214
Weekly Update 214
Weekly Update 214
Weekly Update 214

References

  1. I put an AmpliFi ALIEN unit into a friend's house (this is some really cool kit!)
  2. Trump had some, uh, "interesting" things to say about passwords (I don't know whether it's satire or not, hence Poe's Law)
  3. And while we're on Trump, how about that password of his 🤣 (if it wasn't Victor Gevers that reported this, I'd be suspicious about it)
  4. Sponsored by Varonis. SecurityFWD. A brand new YouTube show from Varonis. Watch Episode 1: How Far can Wi-Fi Travel?

Weekly Update 213

Weekly Update 213

The week's update comes on the back of a very long week for me, but it's good to be "out there" speaking at events even if they are just from the comfort of my own home. There's also more adventures in IoT, Chrome's experiment with URL paths in their omnibox and Apple messing around with MAC addresses on my phone and watch. Oh - and I did manage to track down what my favourite Norwegian beer is following a question from the audience:

Weekly Update 213
Weekly Update 213
Weekly Update 213
Weekly Update 213

References

  1. I've ordered some Xiaomi Aqara wireless switches (these are Zigbee based and will trigger various Home Assistant automations)
  2. Watching the reactions to Chrome's omnibox experiment to hide the path has been... entertaining 🤣 (but seriously, there's an interesting discussion to be had around people's ability to interpret URLs and how much value there is in removing this "noise")
  3. In iOS 14 and watchOS 7, Apple is randomising the MAC when connecting to new networks (good for privacy, but it messes up a bunch of things including my nice Ubiquiti icons)
  4. Sponsored by Varonis. SecurityFWD. A brand new YouTube show from Varonis. Watch Episode 1: How Far can Wi-Fi Travel?

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

You know how some people are what you'd call "house proud" in that they like everything very neat and organised? You walk in there and everything is in its place, nice and clean without clutter. I'm what you'd call "network proud" and the same principle applies to how I manage my IP things:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

That's just a slice of my Ubiquiti network map which presently has 91 IP addresses on it between clients and network devices. Each one has been meticulously customised by both name and icon so that it's immediately recognisable on the map. For example, the Nanoleaf in my daughter's room has the correct image associated to it and her name alongside it so I can easily differentiate it from the one in my son's room. Like I say, network proud, so you can imagine my horror when confronted with the image below:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

"TroysAppleWatch"?! Where's the apostrophe?! And the spaces?! And what's that hideous default icon doing there?! This wasn't the first time I'd seen this either; I'd noticed clients losing their settings for weeks now. I had a theory about what might be the cause so a week ago, I snapped a pic of a bunch of the Apple clients on my network, including their MAC addresses:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

Ah, look at those beautiful names and icons 😊

Now let's look at the details of my watch as they stand today and in particular, the MAC address it has:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

It's completely different to the one I snapped last week. Same watch, same hostname, different MAC address. The root cause quickly became evident: MAC addresses are effectively unique identifiers and the appearance of the same one over and over again provides the ability to track devices. We've known about this for years; even back in 2013, rubbish bins in London were tracking people via their MAC addresses so this isn't a new thing. To address this privacy risk, in their recent OS updates Apple have begun randomising the MAC address on iPhones, iPads and Apple watches which, whilst improving privacy, has kinda messed up my otherwise very clean Ubiquiti setup.

The fix is simply to jump into the Wi-Fi network and look for the "Private Address" toggle:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

Turning that off causes the device to disconnect from the network:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

Before joining back on with a new (now static) MAC address:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

After this the phone came back online and because it's reverted to a MAC address I'd previously associated a name and icon to, everything now looks just fine:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

It's the same deal with the watch which has an equivalent setting:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

One final thing on this: Apple's official docs suggest that whilst the MAC address is unique per network, it's static once assigned to the network:

To reduce this privacy risk, iOS 14, iPadOS 14 and watchOS 7 use a different MAC address for each Wi-Fi network. This unique, static MAC address is your device's private Wi-Fi address for that network only.

That's not consistent with the piece I referenced earlier though which referred to "a feature that periodically changes the MAC address your device uses with each Wi-Fi network", although that was related to a public beta of iOS 14 back in July. But it's also not consistent with my own observations; whilst it's possible that I was looking at changing names and icons for my own devices across different Wi-Fi networks within my own home (I have a primary network, an IoT network and a guest network), the same can't be said of my partner Charlotte who definitely has only ever connected to the primary network. Yet, last week when I was first looking into this, her watch and phone weren't recognised:

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

When we're talking about a home network, I can't see any downside to not randomising the MAC and so far, it's completely solved the problem I was seeing in my Ubiquiti network. Plus, even if the MAC does remain static on a per-network basis, I do still want my own devices in my own home recognised regardless of what SSID they happen to be connected to.

And so, with that done, it's back to being network proud 😊

Customised Ubiquiti Clients and Randomised MAC Addresses on Apple Devices

Weekly Update 212

Weekly Update 212

It's a bit of a mega one this week running over the 1-hour mark, but there's been an awful lot happen during the last week that I reckon is of interest. There's a decidedly adult theme running across the topics not by design, but just by pure coincidence between the Grindr incident, a query I got regarding erasing one's adult website browsing history and the IoT male chastity device full of security holes and potential requiring a grinder (not Grindr!) to remove. We live in interesting times...

Weekly Update 212
Weekly Update 212
Weekly Update 212
Weekly Update 212

References

  1. It's NDC Sydney next week! (I won't "be" there this year, but the show is still going on)
  2. I'm super impressed with the quality on the new GoPro HERO9 Black (more of that to come, including some weekly updates outside the office)
  3. Chowbus got pwned (it's a really odd one)
  4. Your browsing habits may be yours forever if you're not anonymising your IP (what are you doing online today that you'd be happy to be public knowledge not just now, but in the future too?)
  5. The IoT chastity lock with the vulnerability which may require an angle grinder to cut it off you (wow 😲)
  6. Grindr had an absolute shocker of a security vulnerability (I do think they've handled it well, at least once the right people actually knew about it)
  7. The Canadian government is now using HIBP to monitor their domains (they're the 11th gov to be onboarded and I'm sure more will follow yet)
  8. Sponsored by Varonis. SecurityFWD. A brand new YouTube show from Varonis. Watch Episode 1: How Far can Wi-Fi Travel?

Welcoming the Canadian Government to Have I Been Pwned

Welcoming the Canadian Government to Have I Been Pwned

Following in the footsteps of many other national governments before them, I'm very happy to welcome the Canadian Centre for Cyber Security to Have I Been Pwned. The Canadian Centre for Cyber Security now has full and free access to query all Canadian federal government domains across both past and future breaches.

Canada's inclusion in the service brings the total to 11 federal governments across North America, Europe and Australia. I hope to include more parts of the world in the coming months.

Weekly Update 211

Weekly Update 211

This week there's a lot of connected things: connected shoes, connected garage camera and connected GoPro. And then there's Scott's Grindr account. Awkward. Actually, since recording this weekly update the details of the issue have now been released so I'll talk about that in more detail next week. This week there's all the above and, on a more personal note, my relationship with Charlotte. Enjoy.

Weekly Update 211
Weekly Update 211
Weekly Update 211
Weekly Update 211

References

  1. My shoes are connected! (that's the tweet thread of how to update the firmware in them - yep, updating the firmware in my shoes)
  2. My Ubiquiti G3 Micro is up and integrated with Home Assistant to raise motion events (this is super simple and I'll use it to trigger external lights once more Shellys go in)
  3. Got the new GoPro HERO9 Black to start doing some more weekly videos out of the office (might be some jet ski and wakeboard park opportunities in there too)
  4. Charlotte (not sure what I can say here, just watch the video 😊)
  5. Sponsored by: Tines. 22% of breaches begin with phishing (DBIR 2020). Submit suspicious emails and attachments to Phish.ly for free immediate analysis!

Hacking Grindr Accounts with Copy and Paste

Hacking Grindr Accounts with Copy and Paste

Sexuality, relationships and online dating are all rather personal things. They're aspects of our lives that many people choose to keep private or at the very least, share only with people of our choosing. Grindr is "The World's Largest Social Networking App for Gay, Bi, Trans, and Queer People" which for many people, makes it particularly sensitive. It's sensitive not just because by using the site it implies one's sexual orientation, but because of the sometimes severe ramifications of fitting within Grindr's target demographic. For example, in 2014 Egypt's police were found to be using Grindr to "trap gay people" which was particularly concerning in a country not exactly up to speed with LGBT equality. Another demonstration of how valuable Grindr data is came last year when the US gov deemed that Chinese ownership of the service constituted a national security risk. In short, Grindr data is very personal and inevitably, very sensitive for multiple reasons.

Earlier this week I received a Twitter DM from security researcher Wassime BOUIMADAGHENE:

I contact you because i reported a serious security issue to one of the biggest dating applications for gays (Grindr) but the vendor keep ignoring me !
I sent them all the technical details but no way. The vulnerability allow an attacker to hijack any account.

He wanted help in disclosing what he believed was a serious security vulnerability and clearly, he was hitting a brick wall. I asked for technical detail so I could validated the authenticity of his claim and the info duly arrived. On a surface of it, things looked bad: complete account takeover with a very trivial attack. But I wanted to verify the attack and do so without violating anyone's privacy so I asked Scott Helme for support:

Hacking Grindr Accounts with Copy and Paste

Scott's dealt with plenty of security issues like this in the past, plus he helped me out with the Nissan Leaf disclosure a few years ago too and was happy to help. All I needed was for Scott to create an account and let me know the email address he used which in this case, was test@scotthelme.co.uk.

The account takeover all began with the Grindr password reset page:

Hacking Grindr Accounts with Copy and Paste

I entered Scott's address, solved a Captcha and then received the following response:

Hacking Grindr Accounts with Copy and Paste

I've popped open the dev tools because the reset token in the response is key. In fact, it's the key and I copied it onto the clipboard before pasting it into the following URL:

https://neo-account.grindr.com/v3/user/password/reset?resetToken=Isg6zl3q5fZsyAnAB8OCdnRgBSIYfpKkCO0O4pP1WLN0pwuClUqX24ImrLc6bb7T7DWSyFMG5lREHQmS4CsFR5uh8GEYQxF6Z6V5hsi3vSTuilXzgKRRItwdDIjmSWdq&email=test@scotthelme.co.uk

You'll see both the token and Scott's email address in that URL. It's easy for anyone to establish this pattern by creating their own Grindr account then performing a password reset and looking at the contents of the email they receive. When loading that URL, I was prompted to set a new password and pass the Captcha:

Hacking Grindr Accounts with Copy and Paste

And that's it - the password was changed:

Hacking Grindr Accounts with Copy and Paste

So I logged in to the account but was immediately presented with the following screen:

Hacking Grindr Accounts with Copy and Paste

Huh, so you need the app? Alrighty then, let's just log in via the app:

Hacking Grindr Accounts with Copy and Paste

And... I'm in!

Hacking Grindr Accounts with Copy and Paste

Full account takeover. What that means is access to everything the original Grindr account holder had access to, for example, their profile pic (which I immediately changed to a more appropriate one):

Hacking Grindr Accounts with Copy and Paste

Around this time, Scott started receiving private messages, both a request to meet personally and a request for pics:

Hacking Grindr Accounts with Copy and Paste

The conversation with Luke went downhill pretty quickly and I can't reproduce it here, but the thought of that dialogue (and if he'd sent them, his pics) being accessed by unknown third parties is extremely concerning. Consider also the extent of personal information Grindr collects and as with Scott's messages, any completed fields here would immediately be on display to anyone who accessed his account simply by knowing his email address:

Hacking Grindr Accounts with Copy and Paste
Hacking Grindr Accounts with Copy and Paste

A couple of years ago it made headlines when Grindr was found to be sending HIV status off to third parties and given the sensitivity of this data, rightly so. This, along with many of the other fields above, is what makes it so sensational that the data was so trivially accessible by anyone who could exploit this simple flaw.

And as for the website I couldn't log into without being deferred back to the mobile app? Now that I'd logged into the app with Scott's new password, subsequent attempts simply allowed me to authorise the login request myself:

Hacking Grindr Accounts with Copy and Paste

And that's it - I'm in on the website too:

Hacking Grindr Accounts with Copy and Paste

This is one of the most basic account takeover techniques I've seen. I cannot fathom why the reset token - which should be a secret key - is returned in the response body of an anonymously issued request. The ease of exploit is unbelievably low and the impact is obviously significant, so clearly this is something to be taken seriously...

Except it wasn't. The person who forwarded this vulnerability also shared their chat history with Grindr support. After some to-and-fro, he provided full details sufficient to easily verify the account takeover approach on September 24. The Grindr support rep stated that he had "escalated it to our developers" and immediately flagged the ticket as "resolved". My contact followed up the next day and asked for a status update and got... crickets. The following day, he attempted to contact the help / support email addresses as well and after 5 days of waiting and not receiving a response, contacted me. He also shared a screenshot of his attempt to reach Grindr via Twitter DM which, like the other attempts to report the vulnerability, fell on deaf ears.

So I tried to find a security contact at Grindr myself:

I'm conscious that sending a tweet like that elicits all the sorts of responses that inevitably followed it and implies that something cyber is amiss with Grindr. I only tweet publicly once reasonable attempts to make contact privately fail and based on the previous paragraph, those attempts were more than reasonable. A friend actually DM'd me on Twitter and suggested the following:

Not sure that Grindr tweet was necessary, given their DMs are open and they reached out to you fairly soon after

This is why I didn't DM them:

Hacking Grindr Accounts with Copy and Paste

That route was tried and failed and I suggest the only reason their Twitter account publicly replied to me was because my tweet garnered a lot of interest.

After my tweet went out. I had multiple people immediately reach out and provide me with contact info for their security team. I forwarded on the original report and within about an hour and a half of the tweet, the vulnerable resource was offline. Shortly after, it came back up with a fix. In fairness to Grindr, despite their triaging of security reports needing work, their response after I managed to get in touch with the right people was exemplary. Here's how they responded when approached by infosec journo Zack Whittaker:

We are grateful for the researcher who identified a vulnerability. The reported issue has been fixed. Thankfully, we believe we addressed the issue before it was exploited by any malicious parties. As part of our commitment to improving the safety and security of our service, we are partnering with a leading security firm to simplify and improve the ability for security researchers to report issues such as these. In addition, we will soon announce a new bug bounty program to provide additional incentives for researchers to assist us in keeping our service secure going forward.

All in all, this was a bad bug with a good outcome: Grindr did well once I got in touch with them, I believe they're making some positive changes around handling security reports and, of course, the bug has been fixed. Oh - and Scott made some new friends 😊

Weekly Update 210

Weekly Update 210

Wow, 4 years already. Regardless of where I've been in the world or the stresses that have been going on in my personal life, every single week without exception there's been a video. This makes 210 of them now, and these days they're live from a much more professional setup in a location that has absolutely no chance of changing for the foreseeable future. Not exactly the way I saw things panning out 4 years ago, but I guess we've all been a bit blindsided on that front. Anyway, on with the show and there's not a lot on the professional front this week due to downtime with the kids over their holidays, but some good audience questions I hope people enjoy. Next week - something I'm very excited about and it has absolutely nothing to do with tech 😊

Weekly Update 210
Weekly Update 210
Weekly Update 210
Weekly Update 210

References

  1. I've done this video every single week for 4 years, no matter where I've been (that's a link to the first one ever - same same but different)
  2. I've been replacing external Ubiquiti access points with in-wall units... and they're awesome! (I'll gradually go through the house and replace all the wall sockets with these)
  3. Was Activision "hacked" or do people just choose bad passwords? (without evidence to the contrary, my money is on the latter)
  4. Sponsored by: Join the Microsoft Reactor community for workshops, panels and events to expand your skillset across a range of technologies and topic areas

Weekly Update 209

Weekly Update 209

More IoT, more cyber and more Q&A so yeah, business as usual this week. More specifically, a lot of this week's update talks about VPNs and where they still make sense with so much HTTPS all over the place these days. As I say in the vid, blog posts like the VPN one I did this week are often done to help me get my thoughts on a topic straight and a lot of things became a lot clearer for me in doing that. The headline figure out of that post IMHO is that only 2.3% of websites are forcing all connections to be secure courtesy of HSTS preload and the fact that browsers still default to the insecure scheme. More on that (and much more) in this week's update.

Weekly Update 209
Weekly Update 209
Weekly Update 209
Weekly Update 209

References

  1. The whisky tasting put on by Hacktive was a pretty neat digital experience (pic there from the event)
  2. There's been what's reported as the first death as a result of ransomware (I find it hard to believe it hasn't happened before, and it'll definitely happen again)
  3. The "3Ps" of VPN value proposition (where do they still make sense in an increasingly "secure by default" web?)
  4. Sponsored by: safepass.me helps you quickly secure your AD passwords and reduce the risk of Credential Stuffing

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

I want a "secure by default" internet with all the things encrypted all the time such that people can move freely between networks without ever needing to care about who manages them or what they're doing with them. I'm a massive proponent of Let's Encrypt's and Cloudflare's missions to secure the web and of browser paradigms such as HSTS and upgrade-insecure-requests via content security policies to help make it a reality. Yet I also find myself constantly using VPNs for a variety of security and privacy related reasons and it got me thinking - why? I mean what's the remaining gap?

Last month I announced I've partnered with NordVPN as a strategic adviser and as part of that effort, I wanted to be a lot clearer in my own narrative around the value proposition of VPNs, especially as the web implements more encryption across more connections. As I started delving back through my own writing over the years, the picture became much clearer and it really crystallised just this week after I inadvertently landed on a nasty phishing site. I also started giving more thought to privacy and how it's constantly eroded in little bites, a thought process that highlighted just how far we still have to go as an industry, and where the value proposition of a VPN was strongest.

In the end I broke it down into 3 Ps: padlocks, phishing and privacy. Here's the value proposition of a VPN in the modern era:

1. HTTPS Still has a Long Way to Go

This is such a mess it's difficult to even know where to begin, so let me just start with the easy bits then progressively unveil just what a train wreck the current state of encrypted web traffic is. Here's one of our "Big 4" Aussie banks and as you can clearly see by virtue of the padlock, it's served over an HTTPS connection:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Goodo! I know that what's on the page hasn't been modified in transit as it was loaded over the internet nor could anyone intercepting my traffic read it. The last bit is particularly important as I logon and would firstly, like my password not to be eavesdropped on and secondly, would also like to keep my financial information on the website secure. The great thing about the padlock in the browser is that it's assigned automatically by the browser itself; ANZ can't just say "let's whack a padlock up in the omnibar", they only get it if the page (and everything on it) is served securely. If I choose, I can click that padlock and inspect the certificate just to give me that extra peace of mind. Now let's try the mobile app:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

What's the encryption story there? No idea! What I do know is that years ago I reported a bug to ANZ about their mobile app having turned off certificate validation so even though it made an HTTPS connection, it would trust any certificate returned to the app, including one injected by an attacker. Ouch!

I also know that when ANZ updated their app a couple of years ago, they pushed it out by asking people to click on an insecure link that looked just like a phishing attack:

And just to go down the rabbit hole even further, as commendable as the first ANZ screen grab of the HTTPS address in the browser is, you can only get there by first making an insecure request which is what the browser defaults to when you type in "anz.com.au":

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

If you want to get technical about it, yes, there's HSTS involved but it's not preloaded so the first request will always be insecure. But that shouldn't be that surprising given that only 2.3% of the world's top 1 million websites are forcing the first request to be secure:

This isn't meant to be an ANZ-bashing session because let's face it, plenty of banks have had plenty of problems getting their encryption right in the past, but it shows you  just how many place there are for it to go wrong. I was reminded of just what a mess the landscape is just the other day after someone pointed me at a new financial app:

In the ensuing discussions I had about how much we can trust the transport layer, someone pointed out that it was only a few months ago that TikTok was found to be loading videos insecurely allowing the contents of them to be manipulated whilst loading. It's kinda unfathomable to think that this sort of thing is still happening, I was dismayed enough 5 years ago when reporting vulnerabilities likes this, yet here we still are.

Then there's the long, long tail of websites that still to this day, simply don't want to protect their visitors' traffic. For example, one of Australia's most popular websites is the bureau of meteorology, still served insecurely:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

And just in case you thought you'd fix this by using a browser extension such as HTTPS Everywhere, no, you can't:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

This is a baffling approach given they were actually able to respond to a request over HTTPS (so they have a valid cert), but then consciously chose to redirect the traffic to a non-secure address. And before we go down the "yeah but it's a static site so nothing can go wrong" path, all static sites should serve traffic over an encrypted connection for many, many good reasons.

2. A Secure Connection to Satan is Still a Connection to Satan

This tweet by my friend Scott Hanselman has well and truly stood the test of time:

I was reminded of this only a few days ago when I came across yet another Windows virus scam, the kind that's been doing the rounds for a decade now but refuses to die. It all started with a Google alert I have set up for the term "have i been pwned":

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Initially, I was a little bit excited; does Netflix now have a way of checking your address directly against HIBP? Maybe they're plugging into the API directly from the account page there? Cool! However, moments later:

I saved you a copy of the audio as I'm sure the original one will disappear at some point. Imagine some poor unsuspecting person hearing that, seeing the warning on the screen then falling for the scam. These are massively prevalent and, per the screen grab, served over an encrypted HTTPS connection. But as Scott said earlier on, having privacy on your traffic doesn't mean you're communicating with someone you actually want to.

To test a theory, I fired up NordVPN which connected me to an exit node just up the road from me (that IP address is in Brisbane):

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

I've also got CyberSec enabled to kill nasty stuff off which I think it's fair to say, the scamming site above fits the bill:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Hitting the same URL sent to me in the original Google alert led to quite a different result this time:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

This is precisely how it went down just this week with me receiving that Google alert, clicking the link and copping the full brunt of the scam. Clearly, I know better than to fall for it, but it did make me stop and wonder how many people do get taken for a ride by these scams.

And just in case you're wondering, the host name in the image where DNS didn't resolve is different to the final scam site as a lot of these phishes bounce you around across multiple domains. Doing a quick check now, with NordVPN off, my Pi-hole still resolved the domain:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

But turning on NordVPN with CyberSec enabled, the domain was black-holed back to my local IP:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Now to be clear, I still love the Pi-hole (but let's face it, most people aren't going to be installing a Pi in their homes) and you're always going to have DNS block-lists at various states of readiness regarding new malicious domains, but I love CyberSec for the same reason in that by blocking content at the DNS level you can extend the reach well beyond an ad blocker alone. Every browser and every app on the device gets the benefit of known nasty content being binned as it's done at the OS level where DNS is defined and not on a per-client basis.

3. Security != Privacy

This is one of the most obvious value propositions of a VPN, but it deserves being examined in more detail anyway. Let's talk about privacy and I'll break it down into multiple layers beginning with this excellent drawing from Wassim Chegham:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

As soon as we hit the DNS box, privacy starts to go down the toilet as your browser (or other internet connected client) makes a plain text, unencrypted query to a DNS server which is usually your ISP's. Because it's a plain text query, the site your client it querying is immediately observable by anyone sitting on the connection. So what about DNS over HTTPS, or DoH? It solves the interception problem but of course the query still needs to be sent to a DNS server somewhere and at that point, the name being queried and the origin of the query (your IP address) is still visible. From a privacy perspective, this isn't necessarily doing a lot for you.

Side note: we saw a great illustration of how much value ISPs put in being able to intercept DNS queries after the industry body for ISPs in the UK named Mozilla an "Internet Villain" for their push towards DoH. In classic anti-encryption style, the moral neutrality of crypto has led to complaints about increased privacy being used to, well, do things more privately whether they be good things or bad things.

With the DNS dance done, what's the impact on privacy then? Well, per the earlier ANZ example the initial request from the browser is still almost always sent insecurely over HTTP so everyone along the way not only sees where the traffic is going, but can also read and modify the contents of it so again, from a privacy perspective, not good. Per Scott's earlier tweet, only 2.3% of the top million websites in the world are resilient to this courtesy of preloading HSTS. But let's imagine the client has already begun communicating over HTTPS before someone starts poking around in their traffic, what then? That brings us to the next problem:

SNI is Server Name Indication and it was born of a need to host multiple sites and certificates on a single IP address. It means that whilst the contents of your traffic is encrypted, the destination it's being sent to, is not:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

As Cloudflare's CEO wrote in the link above: "SNI leaks every site you go to online to your ISP and anyone else listening on the line". Which led him to talk about ESNI or "Encrypted" SNI. Which is great except... It's only supported in Firefox (Chrome support is going nowhere in a hurry). And it's not on by default. And it requires TLS 1.3. And secure DNS. If you want to check whether it works in your own browser, try Cloudflare's ESNI checker (hint: it almost certainly doesn't work). In time, we may see ESNI get traction, but that time is going to be measured in years, not months, at least for it to gain enough market share for you to genuinely browse the internet in private. Except even then, there's a problem:

Encrypted connections are great, but whilst you're connecting to services from your own IP address, can we really call the connection "private"? If it's my IP address, what can the site I'm visiting determine about me? Here's what NordVPN's "What is my IP address" service told me, right down to my suburb:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

Not only may I not want to share this information with the site I visit, I might not want them knowing I'm the same person coming back on subsequent visits (and no, browsers' incognito and private modes don't fix this). I may also not want them joining the dots on who I am by matching my IP address to other public records; HIBP presently indexes 215 data breaches that exposed IP addresses alongside an extensive array of other personal information. Now, maybe your IP address is dynamic, maybe you browsed a service from 4G and it was your wired connection you used last time, maybe it wasn't the same on multiple different exposures. Maybe...

And now, just to make it even worse, consider all the other locations content gets pulled in from just to load your average web page. Take cnn.com as an example:

Padlocks, Phishing and Privacy; The Value Proposition of a VPN

There are 354 requests required to load the page including requests directly to CNN and their various subdomains, to Adnxs (a tracker), DoubleClick (a tracker) and if you scroll further down the report I've linked to above, amazon-adsystem.com (the hint is in the URL), outbrain.com (guess what - a tracker!) and by then I kinda figured I'd made my point and stopped scrolling. The privacy implications don't stop with the site you're visiting, they cascade all the way down the stack of requests that follow that initial one.

As the old saying goes, privacy isn't necessarily about having something to hide, it's also about not having something you want to share; if you're depressed and going to beyondblue.org.au then you may not wish to share that with other people. If you're having trouble with alcohol and visit aa.org.au then you may not want to share that either. If you're pregnant and hopping over to pregnancybirthbaby.org.au then, again, you may expect to keep that information private (let us not forget the story of how Target managed to "data-mine its way into [a teenage girl's] womb"). Just looking up those URLs I was imagining what sort of conclusions would be drawn about me if someone had access to my connection! (No, I'm not a depressed alcoholic teenager who's expecting...)

But privacy goes well beyond just the obvious issues too, for example folks in the US dealing with the death of net neutrality. When your ISP can see your traffic, they can shape your traffic and remember, HTTPS doesn't fix that problem, at least not today. It extends to censorship too and we start to get into a more contentious area here as that spans everything from the local cafe wifi using deny-lists to government-mandated blocks on content (the latter being particularly contentious regarding certain types of content in certain parts of the world). The point is that the privacy rights assured by a VPN are about a lot more than just protecting your source IP from being exposed to the website you're visiting; it goes well beyond that.

Summary

To be clear, using a VPN doesn't magically solve all these issues, it mitigates them. For example, if a site lacks sufficient HTTPS then there's still the network segment between the VPN exit node and the site in question to contend with. It's arguably the least risky segment of the network, but it's still there. The effectiveness of black-holing DNS queries to known bad domains depends on the domain first being known to be bad. CyberSec is still going to do a much better job of that than your ISP, but it won't be perfect. And privacy wise, a VPN doesn't remove DNS or the ability to inspect SNI traffic, it simply removes that ability from your ISP and grants it to NordVPN instead. But then again, I've always said I'd much rather trust a reputable VPN to keep my traffic secure, private and not logged, especially one that's been independently audited to that effect.

The point of all this is that when we look at the value proposition of a VPN, it's about much more than just protecting a segment of the network that may already have HTTPS anyway. We rarely see TLS implemented to its full potential, phishing remains a massive problem and we have far too little privacy when browsing the web.

Weekly Update 208

Weekly Update 208

The highlight of my week was absolutely getting the Shelly 1 units behind a couple of my light switches working as I'd always dreamed. It just opens up so many automation possibilities that I'm really excited about what I might do in the future with them now. When I get the place to a standard I'm happy with, I'll definitely do a good walkthrough and show how it all works. Until then, this week's update has some general infosec stuff but chief amongst that is the Giggle app situation. So many layers on this one, so many layers...

Weekly Update 208
Weekly Update 208
Weekly Update 208
Weekly Update 208

References

  1. Got the Shelly 1 working absolutely perfectly! (this is precisely what I always envisaged)
  2. Don't say your app is "highly secure" while the browser is literally telling everyone it's "Not Secure" (it's now fixed but still, how do you even start out without HTTPS these days?!)
  3. So apparently Michael McIntyre needed some good new material 🤣 (honestly, I couldn't care less if he actually did, that'd be kinda cool)
  4. If you want to go down a rabbit hole, read my short thread on the Giggle security situation then delve into the tweet threads 😲 (security is one thing, debates on AI detecting females and what makes someone one is quite another)
  5. Sponsored by: The biggest return on security investment is getting your time back. Scale your defenses and regain control with Tines Security Automation.

Weekly Update 207

Weekly Update 207

I kicked off a little bit earlier on this one in order to wrap up before the Burning Minds keynote, and it's interesting to see just how much difference that little sliver of sunlight makes to the video quality. Check the very start of the video versus the very end; this is the sunset slipping through the crack in the fully drawn blinds, make a massive difference. In other news, I'm talking about how I prepare my talks and deliver them timed down to the minute (I had 20 seconds spare on this one), the dramas I'm having with the Shelly units and putting another dozen neon lights in the house, how encryption and hashing are fundamentally different and we should stop conflating the terms and finally, a bit in response to an audience question about how to phrase messaging for a customer attempting to use a Pwned Passwords.

Weekly Update 207
Weekly Update 207
Weekly Update 207
Weekly Update 207

References

  1. I've been really carefully planning the timing of my talks for years now (dug this tweet out as a reminder of how valuable this approach has been)
  2. Thread here on installing the new RGB LED downlights (no, this is not my bedroom!)
  3. Stefán from EVE Online has written a bunch about how to frame messaging when a customer attempts to use a Pwned Password (search through his other posts on the topic too, CCP Games has put a heap of research into this)
  4. Whilst I'm pimping his writing, check out yesterday's post too: Using HaveIBeenPwned, Application Insights and Grafana to detect credential stuffing attacks (this is really neat)
  5. Sponsored by: AppTrana - A Risk Based Managed Cloud WAF that includes Security Assessment of your Site, Instant Managed protection, 24x7 Monitoring & CDN

We Didn’t Encrypt Your Password, We Hashed It. Here’s What That Means:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

You've possibly just found out you're in a data breach. The organisation involved may have contacted you and advised your password was exposed but fortunately, they encrypted it. But you should change it anyway. Huh? Isn't the whole point of encryption that it protects data when exposed to unintended parties? Ah, yes, but it wasn't encrypted it was hashed and therein lies a key difference:

I see this over and over again and I'm not just on some nerdy pedantic rant, the difference between encryption and hashing is fundamental to how at-risk your password is from being recovered and abused after a data breach. I often hear people excusing the mischaracterisation of password storage on the basis of users not understanding what hashing means, but what I'm actually hearing is that breached organisations just aren't able to explain it in a way people understand. So here it is in a single sentence:

A password hash is a representation of your password that can't be reversed, but the original password may still be determined if someone hashes it again and gets the same result.

Let's start to drill deeper in a way that can be understood by everyday normal people, beginning with what a password hash actually is: there are two defining attributes that are relevant to this discussion:

  1. A password hash is one-way: you can hash but you can never un-hash
  2. The hashing procedure is deterministic: you will always get the same output with the same input

This is important for password storage as it means the following as they relate to the previous points:

  1. The original password is never stored thus keeping it a secret even from the website you provided it to
  2. By being deterministic, when the password is hashed at registration it will match the same password provided and hashed at login

Take, for example, the following password:

P@ssw0rd

This is a good password because it has lowercase, uppercase, numeric and non-alphanumeric values plus is 8 characters long. Yet somehow, your human brain looked at it and decided "no, it's not a good password" because what you're seeing is merely character substitution. The hackers have worked this out too which is why arbitrary composition rules on websites are useless. Regardless, here's what the hash of that password looks like:

161ebd7d45089b3446ee4e0d86dbcf92

This hash was created with the MD5 hashing algorithm and is 32 characters long. A shorter password hashed with MD5 is still 32 characters long. This entire blog post hashed with Md5 is still 32 characters long. This helps demonstrate the fundamental difference between hashing and encryption: a hash is a representation of data whilst encryption is protected data. Encryption can be reversed if you have the key which is why it's used for everything from protecting the files on your device to your credit card number if you save it on a website you use to the contents of this page as it's sent over the internet. In each one of these cases, the data being protected needs to be retrieved in its original format at some point in the future hence the need for encryption. That's the fundamental difference with passwords: you never need to retrieve the password you provided to a website at registration, you only need to ensure it matches the one you provide at login hence the use of hashing.

So, where does hashing go wrong and why do websites still ask you to change your password when hashes are exposed? Here's an easy demo - let's just Google the hash from above:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

And here we have a whole bunch of websites that match the original password with the hashed version. This is where the deterministic nature of hashes becomes a weakness rather than a strength because once the hash and the plain text version are matched to each other, you've now got a handy little searchable index. Another way of thinking about this is that password hashes are too predictable, so what do we do? Add randomness, which brings us to salt.

Imagine that if instead of just hashing the word "P@ssw0rd", we added another dozen characters to it first - totally random characters - and then we hashed it. Someone else comes along and uses the same password and they get their own salt (which means their own collection of totally random characters) which gets added to the password then hashed. Even with the same password, when combined with a unique salt the resultant hash will, itself, also be unique. So long as the same salt used at registration is added to your password at login (and yes, this means storing the salt alongside the hash in a database somewhere), the process can be repeated and the website can confirm if the password is correct.

Problem is, if someone has all the data out of a database Wattpad style, can't they just reproduce the salting and hashing process? I mean you've got the salt and the hash sitting right there, what's to stop someone from having a great big list of passwords, picking a salt from the database then adding it to each password, hashing it and seeing if it matches the one from the breach? The only thing hampering this effort is time; how long would it take to hash that big list of passwords for one user's record from the database? How long for, in Wattpad's case, more than a quarter of a billion users? That all depends on the hashing algorithm that's been chosen. Old, antiquated hashing algorithms that were never really designed for password storage in the first place can be calculated at a rate of tens of billions per second on consumer-grade hardware. Yes, that's "billion" with a "b" for bravo and for the more technical folks, that's where you're at with MD5 or SHA-1. How long is a hashed password going to remain uncracked at that rate of guesses? Usually, not very long.

Going back to the example in the tweet at the start of this blog post, Wattpad didn't encrypt their customers' passwords, they hashed them. With bcrypt. This is a hashing algorithm designed for storing passwords and what really sets it apart from the aforementioned ones is that it's slow. I mean really slow, like it takes tens of millions of times longer to create the hash. You don't notice this as a customer when you're registering on the site or logging on because it's still only a fraction of a second to calculate a hash of your password, but for someone attempting to crack your password by hashing different possible examples and comparing them to the one in Wattpad, it makes life way harder. But not impossible...

Let me demonstrate: here's the Wattpad registration page:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

I was interested in what the password criteria was so I entered a single character and was told that it must be at least 6. Righto, let's now check complexity requirements:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

Will 6 all lowercase characters be allowed? Let's submit the registration form and find out:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

Yep 😎

Here's the problem with this and it's all going to bring us back to Wattpad's earlier statement about changing your password: because Wattpad's entire password criteria appears to boil down to "just make sure you have 6 or more characters", people are able to register using passwords like the one above. That particular password - "passwo" - appears in Have I Been Pwned's Pwned Password service 3,649 times:

We Didn't Encrypt Your Password, We Hashed It. Here's What That Means:

It's a very poor password not because of a lack of numbers, uppercase or non-alphanumeric characters (I could easily make a very strong password that's all lowercase), but because of its predictability and prevalence.

Armed with the knowledge that Wattpad allows very simple passwords, I took a small list of the most common ones that were 6 characters or longer and checked them against a sample of their bcrypt hashes. Let's consider a bcrypt hash like this, for example:

$2y$10$5sqOeY.NDcW8vkr47BIG..PeSddwTT/Z8z0MwvF/92NSSh3UsxA.u

The plain text password that generated that hash is "iloveyou". That's in Pwned Passwords 1.6M times and I would argue it's a rather risky one to allow. But because Wattpad's password criteria is so weak, someone (probably many people) used that password and it was easily cracked.

How about this one:

$2y$10$1Gs7jtaGKJjX/7A1GqE2E.0r94/FnKphjp8dyhOVB0jZXirrkfNZW

The plain text version of that one is... wait for it... "wattpad"! These are easy to verify yourself by using an online tool like bcrypt-generator.com that checks a given password against a given hash.

This is why Wattpad recommends changing passwords - because they can be cracked even when using a good password hashing algorithm. They can't be unencrypted because they weren't encrypted in the first place. If they were encrypted and there was genuine concern they may be unencrypted then that would imply a key compromise in which case all passwords would be immediately decrypted.

So there's your human-readable version of what password hashing is. I'll leave you again with the quote from above I'd far prefer to see in disclosure notices and ideally, a link through to this blog post too so people have accurate information they can make informed decisions on:

A password hash is a representation of your password that can't be reversed, but the original password may still be determined if someone hashes it again and gets the same result.

Weekly Update 206

Weekly Update 206

Since I recorded this morning, I've had an absolute breakthrough - I CAN OPEN MY GARAGE DOOR WITH MY WATCH! I know, I know, it shouldn't be this hard and that's a lot of the point I'm making in this week's video. Having said that, some parts have been hard because I've made simple mistakes, but the nature of the IoT ecosystem as it stands today predisposes you to mistakes because there's so freakin' many moving parts that all need to be aligned. More on that in the video, plus some actual infosec content too! More on all of that next week 😊

Weekly Update 206
Weekly Update 206
Weekly Update 206
Weekly Update 206

References

  1. The BBC is now using Pwned Passwords (hitting the k-anonymity API too, plus wrote a great description of it in the aforementioned link)
  2. Cloudflare is a reverse proxy, not a host, and they make it easy to submit abuse reports (but that doesn't mean you can ask them to kill content purely because you don't like it)
  3. Sponsored by: Credential stuffing is currently the biggest threat to organisations, find out how you can protect your network right now with safepass.me

Weekly Update 205

Weekly Update 205

Between still feeling a little groggy after hitting the water hard on an early wake boarding session then my camera overheating and shutting down towards the end of the live stream, this wasn't the smoothest of weekly updates, I still got across everything I needed to. I'm especially excited about those Shelly 1 units for cheaply IoT'ing existing lights and I'm hoping to have some of that up and running next week. Until then, here's episode 205:

Weekly Update 205
Weekly Update 205
Weekly Update 205
Weekly Update 205

References

  1. I got an award! (2020 (ISC)² Global Achievement Awards: Celebrating achievements in cybersecurity)
  2. I'm going to put a bunch of Shelly 1 units behind light switches (this is a really neat way of IoT'ing your house)
  3. New lighting systems in Aus tend to be down lights that fit into 90mm cutouts and plug directly into a mains socket (these are cheap - from ~A$12 - and easy to swap out yourself)
  4. Why oh why oh why do websites keep storing DoB?! (I'm yet to hear a good legitimate reason)
  5. Sponsored by: Edgescan: The award-winning, fullstack, vulnerability management solution. All vulnerabilities expertly verified for false-positive freedom.

Weekly Update 204

Weekly Update 204

It's an extra early one this week and on review, I do look a bit... dishevelled! I run through a whole bunch of things from this week's Twitter timeline and there's some great audience questions this week too so thanks very much everyone for the engagement. Next we'll do it at the other end of the day again and I'm sure there'll be a heap of new stuff to cover before then.

Weekly Update 204
Weekly Update 204
Weekly Update 204
Weekly Update 204

References

  1. The feedback on open-sourcing HIBP has been 99.99% positive (that's about as good as you can ever hope for on the internet!)
  2. I reckon 10TB Western Digital Red drives are the sweet spot for storing data at volume these days (not everyone agrees, of course)
  3. Amazing how many people chimed in on the thread re tamper proof screws (also amazing how many people were completely wrong!)
  4. I'm really not finding any good solutions for universal remotes I can program myself (chime in below if you have any great ideas)
  5. Sponsored by: Join the Microsoft Reactor community for workshops, panels and events to expand your skillset across a range of technologies and topic areas