Security: Public primary keys bad?

I’d like to talk about a security aspect of web apps in general. I’ll try to keep the industry buzzwords to a minimum for the non-programmers.

Ankhos is a web application, an asynchronous one, at that. Asynchronous web applications use many web addresses to load only parts of themselves at once. This can make things seem faster and more responsive to the user.

In any asynchronous web application, web addresses are flying around left and right.  These addresses aren’t typically seen by the user, but simple tools can tell you what these addresses are.  In order to submit a comment or retrieve patient information, we have to hit the server and that means loading a webpage behind the scenes. Here are some fake examples:

Get patient info: /patient/info/3364/

save a comment: /comment/save/

retrieve a comment /comment/get/65356/

You’ll notice that in these addresses there are numbers. They could refer to anything, but 3364 is probably a chart number, and 65356 is probably the internal id of a comment. Pretty cool, right? Well, what does this mean for website security?   If someone saw these addresses and guessed the meaning of these numbers, could patient information be compromised?  We have passwords and secure logins, Can a bad guy still use these urls to gain information about the system?

The short answer is ‘Yes’. He could just put good guesses in to determine the number of users you have or try to associate the volume of activity for a particular user, all without knowing any internals of the system or hacking a password. He might not know the name of the user, but he is gaining information, nonetheless.

However, the security hole here is not the fact that there are identifiers in the urls, but that they have a recognizable pattern that matches data in the application.  One way around this is to assign a random identifier to each entity in your database.  For example, we could generate a random string “9ks0l1900” that corresponds to   chart 3364 and save it with the chart.  the url would then be:

/patient/info/9ks0l1900/

This type of ID makes gathering information about the system without being authenticated much harder.  These numbers would be non-sequential and would not help a bad guy determine the number of users.  Here are a few comments from  Stack Overflow (link, link).  One might exlaim “This is just security through obscurity!”. “Nay”, I would say. This scheme does reduce external knowledge of the system by eliminating patterns available to the public.

One thing this would NOT solve is the ability for a bad guy to associate volume of activity to a given patient. If he really wanted to, he could log when a patient actually WALKS into the office, then monitor the random ids for activity during that stay.  Perhaps he could figure out how much the MDs have to say about this patient… Maybe insurance companies would like to know. Far-fetched, I know. But it is worth considering.

One way to reduce the effectiveness of this strategy might be to have time-outs on these random ids  so that all of the volume information gathered on one day is irrelevant the next day. You would have to make sure the application knows when its urls are out of date, however.

The bottom line is that keys shown to the public are not inherently bad, but if they have a pattern that is relevant to the data in the application, information can be gained without authenticated access.

We are currently focusing on Ankhos’ development in an internally networked environment (not on the public Internet), but these concerns are still valid.

Tags: , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: