That Time I Became A 76-Year-Old New Yorker

Or, what happens when you send an email to the wrong place.

Note, for the time being, I have redacted the names of the company and doctor involved as I am attempting to follow through with a responsible disclosure process for this security issue.

I had something very strange happen to me today.

It all began with a random email to an address that I don’t use much anymore, but still have in Mail. It’s an email account I’ve had for over 13 years, so it still gets the occasional stray email. The subject read as follows:

Followed in quick succession by another one:

Wait, what?

I was confused looking at them. At first I thought they were spam, but they had my firstname and lastname in them and “looked” legit. A quick Google search for “<redacted>” shows it to be some cloud-based patient portal. The URLs in the email matched their site and the email was sent from “redacted-db19” mail server, so everything about this looked legitimate.

I figured one of my doctors had started using this online portal. The first one contained a username and the second one, send a minute later, contained a temporary password.

Well, that’s not very secure. But whatever, there are a lot of amateurs out there, so I better go sign in and change the password.

Imagine my surprise when I logged in with the username in the first email and the temporary password and was immediately prompted to change my password! No verification of the account ownership. Just immediately dropped to an old password, new password, enter new password again style password reset dialog.

Still operating under the assumption that this was sent to me, but making a mental note to talk with whichever of my doctors is using this product about its lack of security, I changed the password and hit submit.

What I saw next shocked me.

There, plain as day, was the full personal information for a “Robert Peck” who lives in New York City. Who was born in 1941. Who has an appointment in February. I saw his full name, address, both cell phone and home phone, even the last 4 of his social (the first 5 were X-ed out, but I’m guessing they have that too). History of visits with doctors.

Everything I would need to convincingly impersonate this person was handed to me with absolutely no verification that I was this person. Even a rudimentary “enter your birthdate” on the password reset dialog would have stopped me, because, obviously, I am not that person.

Then I looked over at the email more closely, and it was sent by <redacted> in care of some doctor in New York City. I should have caught that first, but I completely glossed over it.

So this company, <redacted>, is holding people’s personal identifying information and health information, and literally all you need to get it is a mistyped email address. They practice no good security policy when it comes to handling this type of information.

I thought about this for a little bit and asked my coworkers for advice. This whole thing was inadvertent, but I’ve heard of people getting in trouble for disclosing things like this this in the past. After thinking for awhile, I sent the following email to the doctor’s office in question:

I haven’t heard back yet.

I’m also attempting to contact the company in question, but they have no responsible disclosure email address on their site. So I sent an email to [email protected] with the following message:

I immediately received a response to this one! … a vacation notice telling me this person was out of the office until December 7th.

Doing Software Right Is Hard

Writing software is not for the faint of heart, especially on the web. I get that, because I’ve been doing it for nearly 20 years now. It’s tricky and there are a lot of things that can go wrong. There are a lot of bad actors out there looking to take advantage of any small misstep.

Some of the security vulnerabilities I’ve seen blow my mind. This one at Facebook comes to mind, where a person chained multiple tiny vulnerabilities together into a real exploit. These people, my hat is off to them, because that’s an impressive piece of work.

But some things are simple and have not changed in many, many years. Never trust a user. For accounts that are not created by a user, verify identity before you allow first time access. Never ever ever send a password, even a temporary one, in an email. These things have been known for many years and are considered standard industry practice at this point.

A good example of this is PNC Bank, who currently services my mortgage. When they bought my mortgage from Franklin American, they created an account for me in their online banking system. To get access to this account, I had to enter the birthdate and last 4 of my social security number, and then they physically mailed me a PIN that allowed me to complete the signup process.

Was it inconvenient? Absolutely. Is it the correct way to handle super sensitive financial information? Also absolutely.

At a certain point, when you have been entrusted with someone’s most intimate personal details, it’s time to stop behaving like a startup and more like a bank. Because that’s what you are: a bank of information. People are trusting you to hold their data and not play fast and loose with it. And that means following industry-standard security practices and doing the hard, unglamorous parts of software development.

And please have a responsible disclosure policy for when things go wrong. Preferably one not monitored by a single person who will go on vacation.

Did something I wrote help you out?

That's great! I don't earn any money from this site - I run no ads, sell no products and participate in no affiliate programs. I do this solely because it's fun; I enjoy writing and sharing what I learn.

All the same, if you found this article helpful and want to show your appreciation, here's my wishlist.

Read More

Securely Signing PHP Phar Files With OpenSSL

PHP’s PHAR archives (PHp ARchives, get it?) are a neat development. They’re a way to distribute an entire PHP application as a single archived file that can be executed directly by the PHP intepreter without unarchving them before execution. They’re broadly equivalent to Java’s JAR files and they’re super useful for writing small utilities in PHP.

Google Chrome, Mac OS X and Self-Signed SSL Certificates

I’ve been using Google Chrome as my primary browser for the last few months. Sorry, Firefox, but with all the stuff I need to work installed, you’re so slow as to be unusable. Up to and including having to force-quit at the end of the day. Chrome starts and stops quickly But that’s not the purpose of this entry. The purpose is how to live with self-signed SSL certificates and Google Chrome. Let’s say you have a server with a self-signed HTTP SSL certificate. Every time you hit a page, you get a nasty error message. You ignore it once and it’s fine for that browsing session. But when you restart, it’s back. Unlike Firefox, there’s no easy way to say “yes, I know what I’m doing, ignore this.” This is an oversight I wish Chromium would correct, but until they do, we have to hack our way around it. Caveat: these instructions are written for Mac OS X. PC instructions will be slightly different at PCs don’t have a keychain, and Google Chrome (unlike Firefox) uses the system keychain. So here’s how to get Google Chrome to play nicely with your self-signed SSL certificate: On your web server, copy the crt file (in my case, server.crt) over to your Macintosh. I scp'd it to my Desktop for ease of work. ** These directions has been updated. Thanks to Josh below for pointing out a slightly easier way.** In the address bar, click the little lock with the X. This will bring up a small information screen. Click the button that says “Certificate Information.” Click and drag the image to your desktop. It looks like a little certificate. Double-click it. This will bring up the Keychain Access utility. Enter your password to unlock it. Be sure you add the certificate to the System keychain, not the login keychain. Click “Always Trust,” even though this doesn’t seem to do anything. After it has been added, double-click it. You may have to authenticate again. Expand the “Trust” section. “When using this certificate,” set to “Always Trust” That’s it! Close Keychain Access and restart Chrome, and your self-signed certificate should be recognized now by the browser. This is one thing I hope Google/Chromium fixes soon as it should not be this difficult. Self-signed SSL certificates are used **a lot **in the business world, and there should be an easier way for someone who knows what they are doing to be able to ignore this error than copying certificates around and manually adding them to the system keychain.