Author Archives: Troy Hunt

Welcoming the Norwegian Government to HIBP

Welcoming the Norwegian Government to HIBP

Over the lats couple of years, I've been increasingly providing governments with better access to their departments' data exposed in breaches by giving them free and unfettered API access to their domains. As I've been travelling around the world this year, I've been carving out time to spend with governments to better understand the infosec challenges they're facing and the role HIBP can play in helping them tackle those challenges. During my time in Norway, that included spending time with their National Cyber Security Centre in Oslo. Today, I'm very happy to welcome Norway as the 6th national government onto Have I Been Pwned!

You'll see more national governments come on board in the near future but for now, it's a big welcome to Norways's National Cyber Security Centre!

Weekly Update 165

Weekly Update 165

Yes, I'm in my car. I'm completely disorganised, rushing to the next event and really didn't plan this very well. But hey, what an awesome little soundproof booth it is! That said, I did keep this week deliberately concise... until I went to edit it and then Adobe Premiere (or the NVIDIA drivers on my laptop) decided to turn a 16 minute video clip into a multi-hour shit-fight. That's before the multi-hour upload process too because "Australia" 🙃

Weekly Update 165
Weekly Update 165
Weekly Update 165
Weekly Update 165

References

  1. Scott Helme is running my Hack Yourself First workshop in Amsterdam on Dec 9 & 10 (he's getting awesome reviews on these too)
  2. Apparently, FinecoBank in Italy reckons you should Google your password and not use it if it appears 10 times or more (no, just don't)
  3. You'll also need to pay FinecoBank 0.95 if you'd like to change your password (frankly, I'd be more inclined to change my bank!)
  4. But hey, at least FinecoBank got some press out of it! (Vice has coined their password policies "the worst we've ever seen)
  5. 1Password has had a $200M funding injection (I have enough faith in their leadership to believe they'll do great things with it)
  6. Sponosred by VPN. Mass surveillance is a reality. A VPN can't solve this issue, but it's a great first step. Use one that puts principle before profit.

Weekly Update 164

Weekly Update 164

It's a late, early in the day, hazy, bush-firey Aussie weekly update with a whole bunch of various bits and pieces of interest from throughout the week. The references below will give you a sense of how much I've jammed into this week so I won't repeat it all here in the intro, but I reckon it's a really interesting mix of different things across the industry. Enjoy 😎

Weekly Update 164
Weekly Update 164
Weekly Update 164
Weekly Update 164

References

  1. Nord has had a heap of credential stuffing attacks (or at least a heap of Pastebin entries with creds from attacks)
  2. Whilst it sucks for Nord, they do also have some accountability here (the FTC says that "businesses will no longer be able to play the victim-card")
  3. Veritas (DNA testing) had a breach (whilst DNA data wasn't breached, it begs the question - what would the impact be if it was?)
  4. Finally - free SSL on the Azure app service for custom domains! (non-apex domains only at present, but it's still preview for now so hopefully that's only a temporary restriction)
  5. Sectigo - seriously guys, WTF is this garbage about?! (just read it and shake your head...)
  6. LinkedIn now has a security.txt file! (if your site doesn't have one already, do it because it's free and it's awesome)
  7. Do HSTS from top to bottom or GTFO (this week's blog post was a perfect illustration of why you need it everywhere)
  8. Varonis. Free Video Course: 7 Hidden Office 365 Security Settings You Can Only Unlock with PowerShell

HSTS From Top to Bottom or GTFO

HSTS From Top to Bottom or GTFO

We're pretty much at a "secure by default" internet these days, at least that's the assumption with most websites, particularly so in the financial sector. About 80% of all web pages are loaded over an HTTPS connection, browsers are increasingly naggy when anything isn't HTTPS and it's never been cheaper nor easier to HTTPS all your things. Which meant that this rather surprised me:

HSTS From Top to Bottom or GTFO

Let me break down what's happening here: I'm in (yet another) hotel and on complete autopilot, I start typing "xer" into the address bar which Chrome then dutifully auto-completes for me:

HSTS From Top to Bottom or GTFO

Because it's hotel wifi I expect it to be slow, so I flick over to another tab to do other useful things before switching back to the Xero tab ready to log myself in. Now, imagine for a moment that I'd been confronted with this page:

HSTS From Top to Bottom or GTFO

I've doctored this image to represent what could easily have been a rogue Xero homepage, but would I have hit the login button if I'd seen it? Would I then have entered my credentials on the resulting page, even if still served insecurely? Possibly, although a saving grace would have been Chrome's red indicator once I started typing the password (although in my case, I would have tried to autofill from 1Password and I'd have 2FA to protect me if someone else grabbed it, but you get the point). No really, I pay a lot of attention to this stuff and I'll admit that I could easily have missed the absent padlock. And why is there no HSTS which would have avoided this situation altogether? So I decide to check out the response headers on the login page and behold, there's HSTS:

HSTS From Top to Bottom or GTFO

That's one year's worth of seconds and I visit the site regularly, so what's the problem? Well the obvious one is a combination of the domain being different to the one I originally went to and the HSTS setting not specifying that it should include subdomains. With no such header being returned on the apex domain coupled with my mental autopilot then Chrome autocompleting to xero.com and defaulting to the insecure scheme (as all browsers presently do), meant no HTTPS and the local network effectively MitM'ing the request.

The irony with all this is that Xero obviously recognises the value of HSTS or they wouldn't have used it anywhere, yet by failing to use it on the landing page they leave customers vulnerable to precisely the sort of risk they added HSTS on the login page to prevent. So the moral of the blog post is that HSTS must exist across the entire route of navigation and ideally, also include subdomains and be preloaded. And hey, it's free, easy and one of the best defences going for precisely this threat.

Weekly Update 163

Weekly Update 163

It's been a pretty full week this one with a couple of talks in Sydney followed by another in Melbourne. Then, to top it all off, getting sick hasn't helped and oh boy did this one hurt. Good news is that even just a few hours after recording this video I'm feeling much better, but I desperately need to take a longer period of rest if I don't want a repeat of this any time soon. That'll come, but not for a while yet.

Oh - I forgot to mention it in the vid but I'm also now publishing this podcast via Spotify. Check out the link below if that's your preferred means of consuming podcasts.

Weekly Update 163
Weekly Update 163
Weekly Update 163
Weekly Update 163

References

  1. Catch Scott Helme running Hack Yourself First in Amsterdam on December 9-10 (he's like me, but with a weird accent)
  2. Zoho is now checking users' passwords against Pwned Passwords (that means a welcome change to my talks that feature them!)
  3. Adobe got breached - again (but I'm yet to see any evidence to suggest that puts them at greater future risk, along with other commentary...)
  4. Varonis. Free Video Course: 7 Hidden Office 365 Security Settings You Can Only Unlock with PowerShell

Weekly Update 162

Weekly Update 162

Ah, impending summer on the Gold Coast! It's that time of year when you can just start to sense those warm beach days and it's absolutely my favourite time of year here. Which means... it's time to head off to other events again. Fortunately it's all domestic this time as I head south to Sydney and Melbourne and maintaining my "no fly unless I absolutely have to" stance, it's long, open road drives, copious podcasts and lots of thinking time.

On the infosec side of things, there's a a bunch of HTTPS related content this week plus a couple of (really) sensitive data breaches. I do give a warning at the beginning of this week's update that one of them in particular is pretty, uh, "edgy" and may not be something you want to listen to, but it consumed a bunch of cycles this week and IMHO is worthy of discussion. It's a weird, weird world out there on the web...

Weekly Update 162
Weekly Update 162
Weekly Update 162
Weekly Update 162

References

  1. I'm at Ping IDENTIFY in Sydney on Tuesday
  2. And then Ping IDENTIFY in Melbourne on Thursday
  3. Chrome is changing the way it handles mixed content (good steps forward which amount to eventually upgrading all insecure subresource requests)
  4. Some people actually think that Firefox has killed EV (EV still works just fine, it's only the visual indicator that's gone)
  5. The Zooville breach taught me that zoophilia and bestiality laws are really, really weird (I learned - and saw - many things whilst process this one)
  6. Sponsored by Varonis. Free Video Course: 7 Hidden Office 365 Security Settings You Can Only Unlock with PowerShell

Weekly Update 161

Weekly Update 161

It's my first conference back in Australia since probably about May and I'm experiencing a rare luxury - not flying! I'm sticking to driving some big distances just to get a break from the tyranny that is check-in, security and airport lounges. Seriously, it was beginning to do my head in so now it's cruise control and podcasts for me in the foreseeable future.

This week's travel has brought me to Sydney where the new iPhone got a good workout:

Beyond that, I'm going through some of the highlights (lowlights?) of this week's tweets as that seemed to resonate the last time I did it. Next week will be Gold Coast sunshine and if I time it right, some kangaroos as well 🦘

Weekly Update 161
Weekly Update 161
Weekly Update 161

References

  1. Eventually, the padlock icon will become a redundant artefact of a bygone era (that could occur in 2021 for Chrome)
  2. Certificate misissuance and who's to blame (in 14% of all analysed incidents, CAs intentionally put profits over compliance and industry rules)
  3. Sponsored by Varonis. Free Video Course: 7 Hidden Office 365 Security Settings You Can Only Unlock with PowerShell

Weekly Update 160

Weekly Update 160

Australia! Geez it's nice to sit amongst the gum trees and listen to the birds, even if it's right in the middle of some fairly miserable weather. I'll continue to be here for the foreseeable future too, at least in one state or another. But being back here hasn't stopped me talking about European laws being handled by a local American website nor commentating on the (now well and truly over) debate about the usefulness of visual identity indicators in browsers. But hey, at least the discussion keeps in providing entertaining material!

Weekly Update 160
Weekly Update 160
Weekly Update 160

References

  1. I tweeted about not liking having content blocked when I'm in Europe (no, it doesn't mean I don't like privacy, it means I don't like the choice being taken away from me!)
  2. Is there an elephant in the room? (Or are some people just still fighting a battle for visual indicators that's already been lost?)
  3. But folks pretty quickly ripped into it (sanity prevails, let's treat it as a fruitless attempt to reverse the attitude of most of the major browser vendors)
  4. And just to nail that coffin shut, the thread here is good (it'd be hard to find many people better versed in this stuff than @sleevi_)
  5. Sponsored by Resistance DEX - Privacy-Focused Decentralized Trading - Download it Now!

Weekly Update 159

Weekly Update 159

Well, this will be the last weekly update done overseas for some time as I count down the return to beaches, sunshine and fantastic coffee (yes, I'm confident saying that even whilst in Italy!) It's been a non-stop trip with an attempt of a bit of downtime at the end of it, albeit with limited success. Regardless, this week I'm covering off the last few days travels, reflecting on 10 years of blogging and looking at a really cool use of HIBP related to net neutrality comments lodged at the FCC. Next week... who knows, but at least I'll be home.

Weekly Update 159
Weekly Update 159
Weekly Update 159

References

  1. I went to CERN - it was amazing! (that's a bunch of thoughts and pics from the trip, just staggeringly cool stuff IMHO)
  2. I started a little blog 10 years ago, you'll never believe what happened next... (but seriously, everything I do professionally today started from that one post)
  3. Personal data from a breach was used to spam the FCC (a fascinating look at how HIBP was used to help get to the bottom of it)
  4. Sponsored by Kolide, a User Focused Security app for teams that care about the trust and privacy of their users. Start your free 30 day trial now!

Weekly Update 158

Weekly Update 158

It's been a bit of intense country-hopping since the last update so this one is a consolidated "this week in tweets" version. I actually found it kind of interesting going back through the noteworthy incidents of the week in lieu of having original content of my own, see what you think. Given the coming schedule (and a deep, deep desire for a few days of downtime), the next one might be more of the same so I hope it resonates!

Weekly Update 158
Weekly Update 158
Weekly Update 158

References

Because this week is predominantly about noteworthy tweets, I'm going to do the references a little differently. Firstly, with a sponsor shout-out:

Sponsored by Okta: You wouldn’t roll your own hashing algorithm, so why build your own auth? Secure users in mins with a free dev account.

And then the tweets I discussed themselves:

Weekly Update 157

Weekly Update 157

Hungary! And that's about as much intro as I'm going to do on that because this is going out super later and I'm writing this at the end of a very long day. Only other thing I'll mention is the audio - the Instamic failed to record again so it's now going firmly into the e-waste bin.

Anyway, on a more positive note, enjoy the beautiful sights of the Hungarian parliament before you jump into this week's update:

Weekly Update 157
Weekly Update 157
Weekly Update 157

References

  1. 2FA is far from a perfect beast (read back up through the thread, how do normal everyday people get by if we techies struggle?!)
  2. Banks setting arbitrarily low limits on password complexity really isn't worthy of losing our minds (but that didn't stop people doing that in response to the post anyway!)
  3. Sponsored by Okta: You wouldn’t roll your own hashing algorithm, so why build your own auth? Secure users in mins with a free dev account.

Banks, Arbitrary Password Restrictions and Why They Don’t Matter

Banks, Arbitrary Password Restrictions and Why They Don't Matter

Allow me to be controversial for a moment: arbitrary password restrictions on banks such as short max lengths and disallowed characters don't matter. Also, allow me to argue with myself for a moment: banks shouldn't have these restrictions in place anyway.

I want to put forward cases for both arguments here because seeing both sides is important. I want to help shed some light on why this practice happens and argue pragmatically both for and against. But firstly, let's just establish what's happening:

People are Upset About Arbitrary Restrictions

This is actually one of those long-in-draft blog posts I finally decided to finish after seeing this tweet earlier on in the week:

It feels wrong because 5 digits presents an extremely limited set of different possible combinations the password can be. (There's something a little off with the maths here though - 5 digits would only provide 100k permutations whereas 5 characters would provide more in the order of 1.5B.)

That said, Westpac down in Australia certainly appears to be 6 characters:

Which puts us well north of a billion possibilities again. Want more? CommBank will give you 16 characters:

On the one hand, it's a damn sight more generous than the previous two banks yet on the other hand, why? And while I'm here questioning CommBank's logic, what the hell is going on with this:

Banks, Arbitrary Password Restrictions and Why They Don't Matter

1Password has an open letter to banks on precisely this because its awful advice steeped in legacy misunderstandings of both technology and human brains. That open letter is often used as a reference to persuade banks to lift their game:

So on the surface of it, the whole thing looks like a bit of a mess. But it's not necessarily that bad, and here's why:

Password Limits on Banks Don't Matter

That very first tweet touched on the first reason why it doesn't matter: banks aggressively lock out accounts being brute forced. They have to because there's money at stake and once you have a financial motivator, the value of an account takeover goes up and consequently, so does the incentive to have a red hot go at it. Yes, a 5-digit PIN only gives you 100k attempts, but you're only allowed two mistakes. Arguably you could whittle that 100k "possibilities" down to a much smaller number of "likely" passwords either by recognising common patterns or finding previously used passwords by the intended victim, but as an attacker you're going to get very few bites at that cherry:

Next up is the need to know the target's username. Banks typically use customer registration numbers as opposed to user-chosen usernames or email addresses so there goes the value in credential stuffing lists. That's not to say there aren't ways of discovering someone's banking username, but it's a significantly higher barrier to entry than the typical "spray and pray" account takeover attempts.

Then there's the authentication process itself and it reminds me of a discussion I had with a bank's CISO during a recent workshop. I'd just spent two days with his dev team hacking themselves first and I raised the bollocking they were getting on social media due to a new password policy along the lines of those in the tweets you see above. He turned to me and said, "Do you really think the only thing the bank does to log people on is to check the username and password?" Banks are way more sophisticated than this and it goes well beyond merely string-matching credentials; there's all sorts of other environment, behavioural and heuristic patterns used to establish legitimacy. You won't ever see a bank telling you how they do it, but those "hidden security features" make a significant contribution to the bank's security posture:

Then there's the increasing propensity for banks to implement additional verification processes at key stages of managing your money. For example, one of the banks I regularly use sends me a challenge via SMS whenever setting up a new payee. Obviously, SMS has its own challenges, but what we're talking about now is not just needing to successfully authenticate to the bank, but also to prove control of a phone number at a key stage and that will always be more secure than authentication alone.

And if all of this fails? Banks like ING will give you your money back:

Now, compare all this to logging on to catforum.com:

Banks, Arbitrary Password Restrictions and Why They Don't Matter

How much sophistication do you think is behind those username and password fields in that vBulletin forum? Exactly, it's basic string-matching and this is really the point: judging banks by the same measures we judge basic authentication schemes is an apples and oranges comparison.

However, I disagree with banks taking this approach so let me now go and argue from the other side of the fence.

Banks Shouldn't Impose Password Limits

There are very few independent means by which we can assess a website's security posture in a non-invasive fashion. We can look for the padlock and the presence of HTTPS (which is increasingly ubiquitous anyway) and we look at the way in which they allow you to create and use passwords. There are few remaining measures of substance we can observe without starting to poke away at things.

So what opinion do you think people will form when they see arbitrary complexity rules or short limits? Not a very positive one and there are the inevitable conclusions drawn:

Hey [bank], does that 16 character limit mean you've got a varchar(16) column somewhere and you're storing passwords as plain text?

As much as I don't believe that's the case in any modern bank of significance, it's definitely not a good look. Inevitably the root cause in situations like this is "legacy" - there's some great hulking back-end banking solution the modern front-end needs to play nice with and the decisions of yesteryear are bubbling up to the surface. It's a reason, granted, but it's not a very good one for any organisation willing to make an investment to evolve things.

But beyond just the image problem, there's also a functional problem with arbitrarily low password limits:

I've been through this myself in the past and I vividly recall creating a new PayPal password with 1Password only to find the one in my password manager had been truncated on the PayPal side and I was now locked out of my account. This is just unnecessary friction.

Summary

So wrapping it all up in reverse order, arbitrary low limits on length and character composition are bad. They look bad, they lead to negative speculation about security posture and they break tools like password managers.

But would I stop using a bank (as I've seen suggested in the past) solely due to their password policy? No, because authentication in this sector (and the other security controls that often accompany it) go far beyond just string-matching credentials.

Let's keep pushing banks to do better, but not lose our minds about it in the process.

Weekly Update 156

Weekly Update 156

Turns out it's actually a sunny day in Oslo today, although it's the last one I'll see here for quite some time before heading off to Denmark then other European things for the remainder of this trip. I'm talking a little about those events (all listed on my events page), this week's changes to EV, more data breaches and a somewhat semantic argument about the definition of "theft".

Weekly Update 156
Weekly Update 156
Weekly Update 156

References

  1. Entrust are convinced you should still pay them for EV certs (even though the primary value proposition they're still promoting is now gone...)
  2. Scott killed a million bucks worth of EV certs (it turns out that extended validation isn't always so... extended)
  3. The Void.to hacking forum got breached and is now in HIBP (a lot of private messages in there people really wouldn't want being traced back to them)
  4. Garmin in South Africa had a whole bunch of credit cards siphoned off (looks like a classic Magecart attack)
  5. Does a data breach actually constitute "theft" given the original owner isn't deprived of it? (that's a link to the Twitter thread on it, I think the term is a bit overloaded TBH)
  6. Sponsored by Okta: You wouldn’t roll your own hashing algorithm, so why build your own auth? Secure users in mins with a free dev account.

Weekly Update 155

Weekly Update 155

From the emerging spring to the impending autumn, I'm back in Oslo at the beginning of another series of European events that'll take me across Norway, Denmark, Hungary and Switzerland. This week's update comes from under the glow of a warm outdoor heater at ridiculous o'clock as my sleep cycle keeps me making early starts. But it's all transient and by this time next month I'll be back to a very warm, very familiar Aussie landscape. For now, here's what's new on my side:

Weekly Update 155
Weekly Update 155
Weekly Update 155

References

  1. There's 419M Facebook users' phone numbers floating around (looks like abuse of a now deprecated feature and no, it's not going into HIBP)
  2. Chrome 77 is about to hit and finally kill off EV for good (that'll be the end of org names next to the address bar, but will it be the end of commercial CAs telling people that?)
  3. It's ok to let old tech die (do we really want organisations beholden to perpetually supporting legacy devices merely for historical purposes?)
  4. Okta is my new blog sponsor for this week (friends don't let friends write user auth!)

Weekly Update 154

Weekly Update 154

How's that for a setting in this week's video? 🌴 First day of spring here which aligned with a father's day on the water:

Back on business as usual, there's the SIM hijacking issue with Jack Dorsey's Twitter account, more data breaches and joyously, the HIBP API being back in full swing with the 500 subscription limit issue on Azure's APIM now being overcome. Next week's update will be from Oslo so a rather different scene, followed by some other cool places across Europe in the ensuing weeks.

Weekly Update 154
Weekly Update 154
Weekly Update 154

References

  1. I'm at NDC TechTown in Konsberg next week (closing keynote on Thursday, I probably should get onto that...)
  2. Jack's Twitter account posted some nasty content after a SIM hijacking incident (how many of your own accounts can be controlled by someone who owns your SIM?)
  3. You can now sign up for new subscriptions to the HIBP API again! (so it's basically doing precisely what's described in that blog post - again)
  4. Big thanks to strongDM for sponsoring my blog over the last week! (see why Splunk's CISO says "strongDM enables you to see what happens, replay & analyze incidents. You can't get that anywhere else")

Weekly Update 153

Weekly Update 153

Australia! Sunshine, good coffee and back in the water on the tail end of "winter". I'm pretty late doing this week's video as the time has disappeared rather quickly and I'm making the most of it before the next round of events. Be that as it may, there's a bunch of new stuff this week not least of which is the unexpected limit I hit with the Azure API Management consumption tier. I explain the problem in this video along with a bunch of other infosec related bits. I'll do another one from Aus later this week (if I can stick to schedule) and will try and find another nice little spot. Until then, enjoy:

Weekly Update 153
Weekly Update 153
Weekly Update 153

References

  1. I hit an unexpected limit on the consumption tier of the Azure API Management (it's frustrating, but I'm working with Microsoft on a longer term fix and mitigating the issue in the interim)
  2. The responses to DigiCert's survey on reducing maximum cert lifespans make for sad reading (there are much bigger root causes within enterprises that need sorting out)
  3. Hostinger got themselves breached (I still think the wording here is poor, surely we can do better as an industry?)
  4. Big thanks to strongDM for sponsoring my blog over the last week! (see why Splunk's CISO says "strongDM enables you to see what happens, replay & analyze incidents. You can't get that anywhere else")

Weekly Update 152

Weekly Update 152

I made it out of Vegas! That was a rather intense 8 days and if I'm honest, returning to the relative tranquillity of Oslo has been lovely (not to mention the massive uptick in coffee quality). But just as the US to Europe jet lag passes, it's time to head back to Aus for a bit and go through the whole cycle again. And just on that, I've found that diet makes a hell of a difference in coping with this sort of thing:

This week it's almost all about commercial CAs and their increasingly bizarre behaviour. It's disappointing to see disinformation and privacy violations from any organisations, but when it's from the ones literally controlling trust on the web it's especially concerning. Maybe once they're no longer able to promote EV in the way they have been that will change, but I have a feeling we've got a bunch more crap to endure yet. See what you think about all that in this week's update:

Weekly Update 152
Weekly Update 152
Weekly Update 152

References

  1. Reminder: If you're using the HIBP API to search for email addresses, get yourself onto V3 ASAP! (you've got 2 days until the old versions die)
  2. Chegg had 40M accounts breach with unsalted MD5 password hashes! (it was April last year, now it's searchable in HIBP)
  3. Extended Validation Certificates are (Really, Really) Dead (I've been saying it for ages, but both Chrome and Firefox have really nailed it now)
  4. DigiCert is rejecting the proposal to reduce maximum certificate lifespans (uh, except for that post a few years ago when they thought it was a good idea...)
  5. Sectigo leaked the personal info of a do-gooder which resulted in him receiving a threatening letter (there's all kinds of things gone wrong here)
  6. Big thanks to strongDM for sponsoring my blog over the last week! (see why Splunk's CISO says "strongDM enables you to see what happens, replay & analyze incidents. You can't get that anywhere else")