A few weeks ago I had to have a conversation with a vendor about credentials. Despite some push back from our side, they insisted that their Bearer Token style authentication key for HTTP requests was safe from MitM + Replay attacks. The token was to be used from a user's device (their phone). They claimed it must be safe because the API access that uses this token is protected by HTTPS/TLS/SSL. In short: yes it's protected from external snooping, but it's not safe unless you fully trust all of your users and their devices, which you should not. (aside: that talk was from 2015? that's surprising).

This reminded me of both an inadequacy in how we generally speak with vendors, and also a Kafkaesque conference call…

It is not uncommon for vendors to send credentials by email. For a long time I pushed back on this, but the practice became seemingly so common (and the security concerns of this approach such a foreign idea to vendors) that I've mostly stopped bothering, unless it's a credential that my team needs to care about. If you broadcast your key in a place others can see it, that's on you. We might mention it, but because there's not a great universal way to use an established secure method to communicate (this is the first problem: the inadequacy of secure communication with vendors), it's usually so much of a hassle that I don't feel as strongly about identifying this kind of misstep when it's solely someone else's problem if/when it leaks. That might make me complicit in the worsening-of-everything, but honestly, these days I'd spend so much of my/their time chasing this kind of thing down, that it seems less worth it than in the past, and I've got my own work to do.

There was one client, though, where this happened all the time with their vendors (and themselves). It happened so often that we had to speak up about it whenever someone delivered a long-lasting security credential in an insecure matter. It seemed like every week we had to send a "please invalidate this credential and send it via the secure method we established at the start of this relationship"—which, in most cases, was Keybase.

There's really not a great way to get normals to send secure messages with the tools they already have.

Anyway, this one client, and this one conference call went something like this: we get about 30 people together on a giant "go/no-go" call. These are mostly the big client, but in this case we're one of the vendors, and there are at least 3 other vendors on the call. When it gets to be our turn I say "we're go on our stuff, but we'd like Vendor X to invalidate the key they sent Vendor Y by email earlier today and generate a new one; even if we consider this email secure (which we don't), we don't want to have this key and you sent it to us in the big email thread."

Vendors on this project were used to us saying this kind of thing. They didn't care. We were—in part—getting paid to care, so we brought it up. There was non-visible eyerolling, but we eventually all agreed that Vendor X would regenerate and send to Vendor Y.

Next thing we know, and still on the conference call, the representative from Vendor X says "ok, Dave, I regenerated the key. It's a7b 38…" I break in as soon as I realize what's going on and I say "STOP. PLEASE. The whole point of regenerating is that we should exercise Least Privilege and there are a lot of people on this call that don't need this key—they should not have it." More eye rolling, but Vendor X's person says "ok, Dave; I'll call you directly then."

Slight pause in the big conference call and we hear Dave (from Vendor Y) say "Hello?" then we hear Vendor X say "Hey Dave. It's Kathy. Okay, the key is a7b 38…" Sure enough, Kathy called from her mobile phone to Dave's mobile phone, and neither of them muted themselves. We heard both sides of the conversation and everyone got the key yet again.

I think we made them regenerate a 3rd one, but this kind of complete lack of diligence is a main factor in me noping out of pestering vendors about regenerating credentials that are compromised by neglect, unless we have a specific mandate to do so (or if the credentials are ours to regenerate).