Some days, it just feels like the world is working against you or in the case of today, like it's all just going to metaphorical security hell. As much as we like to keep pushing the needle further around the "strong security dial" with things like security headers, strong HTTPS implementations and robust hashing algorithms, every now and then we need to take a moment to remember just how low the bar still remains and that frequently, we can't even get the basics right.
Here's a bunch of examples just from today that illustrate how far we still have to go.
Password complexity rules still suck (for your own good, allegedly)
Earlier today I saw my mate Lars Klint call Etihad Airlines to account on behalf of their password complexity rules:
Excuse me @EtihadAirways, why do you insist on making my passwords worse? pic.twitter.com/gbntva8Skn
— Lars Klint (@larsklint) June 30, 2016
Firstly, why we still have this problem is beyond me. The entire premise of arbitrarily limiting password lengths this way is flawed. Not only does it suggest that just maybe - maybe - the problem is that they're trying to fit the password into that varchar(10) column in the database thus implying no cryptographic storage, it fundamentally weakens the choice of passwords available to the user. The screwy rule around what it begins and ends with only makes it worse and to add insult to injury, they'll happily let you create an account with the password of "password1".
So why does Etihad do this? Because "security":
@larsklint Hi Lars, we advise you to do it because of security reasons *Lina
— Etihad Airways (@EtihadAirways) June 30, 2016
Wait - what?! No really, it's in your own best interests:
@larsklint As we mentioned earlier it is because of security reasons, Thank you for your understanding *Lina
— Etihad Airways (@EtihadAirways) June 30, 2016
Ok, we're used to screwy responses by Twitter account operators but clearly there is still an underlying problem here.
Sites are still breaking password managers
The Etihad thing was annoying but I decided to get on with life and go do something useful, something like changing my PayPal password. So I headed over to the change password page:
I use 1Password to generate all my passwords so I right-click on the field then ask it to generate me a new one with the usual 30 characters of randomness:
It fills in the form and I change the password just fine. It then asks me to log back in which I try to do but, well, then this happens:
Shit. That's an account with money in it and I can't login! So I'm looking at the page trying to figure out what the hell is going on because there's absolutely no doubt whatsoever the password is correct, 1Password just stored the generated one for me. On a hunch, I took a look at the DOM inspector:
Huh, no max length so it's not truncating it. On another hunch, I headed over to the registration form and inspected the password field there:
Oh c'mon, they're truncating passwords there but not at login? So I chop off the last 10 chars of my new password and bingo - I'm in!
Same deal as Etihad in many ways and this is just a totally screwy implementation. I didn't count the obfuscated chars on the change password page and inevitably there were only 20 of them and not 30 but that implementation fundamentally broke my ability to use a password manager to create a new password. Frankly, I would have preferred to see them simply truncate it on the back end and let me live with the false sense of security that I had 30 chars when I only had 20. Or even notified me when they saw 20 chars appear in the form without a single key press that "hey, looks like you just generated a password, thought you'd like to know that we're gonna screw that up on you". Just breaking my login is ridiculous.
HTTPS remains hard (except it's not)
Let's go back to Etihad because after seeing their screwy password approach, I was pretty sure other things would be broken too. They didn't disappoint:
Hi @EtihadAirways, I get a warning that your login page is not secure, do you have a secure one I can use? pic.twitter.com/Ln7YCjsoSD
— Troy Hunt (@troyhunt) July 1, 2016
So why is this? A quick look at the console tells all:
Let me demonstrate the problem and then the fix. This lovely flight attendant may not actually be a flight attendant at all - I can't trust her because she was loaded insecurely:
However, this one really is a legitimate flight attendant as she was loaded over a secure connection:
This image is the one causing the first warning in the console image above and it can very happily be served over HTTPS. We can see her embedded in the page as follows:
The HTTP scheme is explicitly used instead of the HTTPS one. Either that or even better, had they just used a protocol relative link with a bit of src="//media.etihad... then everything would have been fine. It's such a pointless mistake made even worse due to the fact that she only even appears when you hover over a social link in the footer (and even then, her image hasn't been correctly sized):
It's not just Etihad though, for some time now I've used Qantas in many of my workshops to illustrate the same thing:
In fact, this is a great demo - go to https://www.qantas.com and watch as Chrome momentarily shows a green padlock... then yoinks it away! Actually, Qantas is even worse in many ways as the page doesn't load securely by default yet includes your frequent flyer login. Ah well, it's not like you'll be using an airline's website in insecure places like, oh, on free public wifi at an airport...
But Qantas is worse still because of this:
They're posting off to an insecure form! But they can't do it securely in the first place (yet) anyway because the host at qantas.resultspage.com.au doesn't have a valid certificate - it's only valid for *.resultspage.com which doesn't include the .au TLD.
This is all so, so simple yet here we are, unable to get the most fundamental aspects of web security right. At least there's good training material available on the web...
Crazy password advice (and censoring critics)
Continuing my day of crazy app sec, someone sent me over a link to a piece on how to create your own encrypted password using PHP. Of particular interest was the following piece of code; take a moment to absorb this:
This is simply character substitution - for each character in the input string, replace it with another character via a convoluted series of sub string, modulus and ASCII value operations. Repeat in reverse order to "decrypt". This is reminiscent of my post from a few years ago about The problem with website security is us! which shows similar screwy approaches.
I almost wouldn't have bothered including the story in this post because hey, we've all done some screwy code things in the past but we learn and move on, right? Except in this case, the guy started deleting comments. On a hunch that this may occur, I snapped a quick screen cap earlier on:
Now I can see how some of these comments could feel very confrontational. There's a way to give feedback which can be both kind and constructive and whilst I appreciate the passion with which these (and others out of screen) responded, they probably could have done so a little more... diplomatically.
But what frustrates me far more is that despite the comments outlining the problems, not only did nothing change in the original post but the author elected to delete those comments so that others couldn't see the criticism. This is reckless - people will Google "encrypt passwords in php" and potentially find this piece and literally copy and paste the whole thing (betcha they even copy the "key"). I've actually had a post in draft for a while titled "We all get stuff wrong, now (wo)man up and take it constructively" and it refers to this exact pattern - a badly written post (albeit one that's an innocent mistake) and then the deliberate censoring of critics. I appreciate my calling him out here draws further attention to the issue and that itself may be uncomfortable for him, but I'm more worried about the downstream impact on others who read this without knowing what's wrong with it than I am about hurting the feelings of someone who won't accept criticism.
With the hope of leaving kind, constructive and relevant advice, I posted a comment myself which I'll leave here just in case it too disappears:
Update: The following day, the author updated the post with a bcrypt example and acknowledged the comment I left on his site (which still remains at the time of writing). Kudos to him!
Security is often mixed, crazy messaging
Then there was Pandora and how's this for a bunch of screwy, mixed messaging: We start with the piece I published to my Security Sense column earlier today about over-communicating breach incidents. In there, I talk about this message from Pandora which I received earlier in the week:
Read that piece mentioned above for why I don't think what they've done here is wise, but that's not the real issue I have with them. It all started when I went to the site to login and take a look see at what was new there:
Ok - hang on - just to login (which many people would do to then change their password after receiving the above email), I need to enable one of the most frequently exploited pieces of code on the planet?! In an era where we've all unanimously agreed that Flash is not just on the way out but should by now be well and truly pushing up daisies, this is hard to fathom. Yes, I get that their legacy music player has a dependency on Flash but I'm not trying to play music, I'm just trying to login!
Ok, I'll humour them, let's enable Flash then login:
This makes the @pandora_radio security notice all the more bizarre - why have an insecure login guys? pic.twitter.com/Y0FgYS959X
— Troy Hunt (@troyhunt) July 1, 2016
Oh c'mon! The screwy thing about this is that login is still just an HTML form, but you can't use it unless you enable Flash.
Because security is just pointless
Or at least that's how it feels sometimes. For all the progress we make in so many areas, seeing a flood of screwy things in one day just makes you shake your head. It'd be depressing, if it weren't for the fact that all the sorts of behaviours you see here have given me a very fulfilling career!
I'll leave you with one last screwy security thing of the day:
I hacked a Linux-powered rifle last year. Here's how the vendor responded: pic.twitter.com/7A05SvKYw1
— Runa A. Sandvik (@runasand) July 1, 2016
As if the very premise of civilians having guns in the first place wasn't already an unfathomable concept for most of the world that doesn't live in the US (and a good whack of them who do, by all accounts), but someone made a wifi enabled version! And because wifi isn't inherently insecure enough as it is, someone's gone and connected a consumer "device" to it that can fire bullets. And holy shit, look at the size of this thing!
Not exactly "for self-defence" or "should the British invade"! And then it talks over 802.11. And it can be hacked. But it's ok so long as hackers don't get within 100 feet. I think I'm over security for today...