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

Written by Rebecca Peck · 8 minute read

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 support@ 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.