Security

As best I understand it, one of the most effective SEO things you can do is to repeat all the important words on your site down the bottom of the page. To save it from looking weird, you make the text the same colour as the background so people can't actually see it, but the search engines pick it up. Job done, profit! I think this is the way we did it in 1999. I don't know, I can't recall exactly, but I know I don't know and I'll happily admit to being consciously incompetent in the ways of SEO. But that's cool, I know the things I understand well and those I don't and when I get the latter...

Edit: The following day, I loaded another set of passwords which has brought this up to 320M. More on why later on. Last week I wrote about Passwords Evolved: Authentication Guidance for the Modern Era with the aim of helping those building services which require authentication to move into the modern era of how we think about protecting accounts. In that post, I talked about NIST's Digital Identity Guidelines which were recently released. Of particular interest to me was the section advising organisations to block subscribers from using passwords that have previously appeared in a data breach. Here's the full excerpt from the authentication & lifecycle management doc (CSP is "Credential Service Provider"): NIST isn't mincing words here,...

Only a couple of months ago, I did a talk titled "The Responsibility of Disclosure: Playing Nice and Staying Out of Prison". The basic premise was to illustrate where folks finding security vulnerabilities often go wrong in their handling of the reporting, but I also wanted to show how organisations frequently make it very difficult to responsibly disclose the issue in the first place. Just for context, I suggest watching a few minutes of the talk from the point at which I've set the video below to start: Time and time again, I run into incidents where good people hit brick walls when trying to do the right thing. For example, just this weekend I had a Twitter...

In the beginning, things were simple: you had two strings (a username and a password) and if someone knew both of them, they could log in. Easy. But the ecosystem in which they were used was simple too, for example in MIT's Time-Sharing Computer, considered to be the first computer system to use passwords: We're talking back in the 60's here so a fair bit has happened since then. Up until the last couple of decades, we had a small number of accounts and very limited connectivity which made for a pretty simple threat landscape. Your "adversaries" were those in the immediate vicinity, that is people who could gain direct physical access to the system. Over time that...

Last week I wrote about how Life Is About to Get a Whole Lot Harder for Websites Without HTTPS. Somewhere in the comments there, the discussion went off on a tangent about commercial CAs, the threat Let's Encrypt poses to them and subsequently, the value (or lack thereof) posed by extended validation (EV) certificates. That discussion boiled over onto Twitter with many vocal opinions from different camps. This post attempts to lay the arguments out in a more cohesive fashion than Twitter permits. But firstly, let's get back to the original blog post which I made due to the fact that come October, Chrome 62 will begin doing this: There are two important things happening here: Any page including a...

In case you haven't noticed, we're on a rapid march towards a "secure by default" web when it comes to protecting traffic. For example, back in Feb this year, 20% of the Alexa Top 1 Million sites were forcing the secure scheme: These figures are from Scott Helme's biannual report and we're looking at a 5-month-old number here. I had a quiet chat with him while writing this piece and apparently that number is now at 28% of the Top 1 Million. Even more impressive is the rate at which it's changing - the chart above shows that it's up 45% in only 6 months! Perhaps even more impressive again is the near 60% of web requests Mozilla...

Last week, The AA in the UK came spectacularly undone when attempting to cover up a data breach. I wrote about them while describing The 5 Stages of Data Breach Grief but in short, they consciously elected not to notify subscribers after being alerted to the disclosure of 13GB worth of publicly accessible database backups back in April: A follower just advised they recently notified @TheAA_UK about 13GB of exposed DB backups. It's not clear if they ever notified customers. pic.twitter.com/gOGYJSfVep— Troy Hunt (@troyhunt) June 26, 2017 They then sought to play down the severity of the exposure by claiming that no credit card data was compromised: Which was completely and utterly false:...

When you see something play out enough times, you start to notice patterns. I was reflecting on this today as I watched The AA rapidly digging themselves in deeper and deeper after publishing 13GB worth of customer data to the internet, including partial credit card data. Which they denied: The AA Shop data issue is now fixed, No Credit Card info was compromised & an independent investigation is under way. We're sorry.— The AA (@TheAA_UK) July 3, 2017 Problems is, this statement is entirely false as Graham Cluley subsequently pointed out: Yes - despite what it says - AA customer credit card data was exposed https://t.co/JJGwjj1DDN pic.twitter.com/R8mMOTzUbS— Graham Cluley...

I watched a discussion unfold on Twitter recently which started like so many of the security related ones I see: When website errors make no sense! @Argos_Online my password is more complex than your system can handle. What gives? @troyhunt #insecurity pic.twitter.com/64VA7qINGP— Jon Carlos (@billywizz) June 10, 2017 This was a very misleading error message on Argos' part and as it turns out, what it really mean was that they only allowed up to 20 characters in passwords. It's the classic arbitrary limit story; for various reasons which may include legacy dependencies, ignorance or very often, a database column of limited length (which then implies no password hashing and quite likely plain text storage), Argos...

A little while back, I wrote about Website enumeration insanity and how our personal data was being mishandled. In a nutshell, an enumeration risk boils down to a feature on a website allowing anyone to "ask" if a user exists on the website with the site then returning a positive or negative response. For example, to this day you can go to Adult Friend Finder's password reset page, plug in anyone's email address and they'll happily tell you if they'd signed up for a bit of swinger sex action. (Or at least whether their address is on the site, someone else could have entered it into the registration form. Honestly...) Now all that's bad, but as I pointed...