1

I am working on a project that uses a combination of a web based framework (Django) and an installed app (Python) for the purpose of data entry/upload. I will have to send medical records over the web and I've been trying to come up with a way to make a system that is cryptographically sound. I figure I can use django's auth_user table which contains usernames and hashed and salted passwords. The default format for this field is

algorithm_____$#iter$Salt_____$_________hashedpassword_____________________
pbkdf2_sha256$100000$6ID5G1Xym$s2snCtv3UncgSfGIS49d38ksv9LYuLGEsvWQwU66/xE=

If I have password and the salt, I can recreate the hashed password which I want to use as the key for AES. The problem is that the salt is randomly created by django during password creation.

My question is, would it create any insecurities to send the salt along with the encrypted information?

I'm thinking that it would not because the salt is assumed to be known by an attacker anyway.

Side question: Is AES considered secure for medical information? Are there any pitfalls I should be aware of?

horriblyUnpythonic
  • 113
  • 4
  • 4
    Why are you doing projects containing sensitive, personal information if you don't have a clue what you are doing? This is one of those things which you shouldn't be doing if you need to ask. – Lucas Kauffman Jan 15 '14 at 20:07
  • Luckily, my job ended up intersecting with something that I find interesting. I was under the impression that quite a bit of those involved in this field were self taught. Is there any literature you might direct me to, if you feel I am lacking some fundamental knowledge? I would be very grateful for the heads-up. – horriblyUnpythonic Jan 15 '14 at 22:55
  • I put some resources at [the end of this answer](http://crypto.stackexchange.com/a/10468/1501), specifically recommend the udacity applied crypto course and Dan Boneh coursera course. – dr jimbob Jan 16 '14 at 07:09

1 Answers1

2

The standard advice is: Don't roll your own security system and expect it to be secure, especially in an area with strong regulations for data security and especially if you are new to the field (though its good to ask questions).

First, your intuition is right; there's no big problem in revealing your salt, which does not need to be kept secret like the password (and the hash). All the salt needs to be is to have a high probability of uniqueness (so all accounts aren't easily attacked in parallel).

Next, AES is a secure block cipher and when used in a proper block cipher mode provides a good deal of security. ECB mode definitely should be avoided as it often leaks information. CBC and CTR modes are secure to keep the contents of your file secret, however these modes do not come with any sort of authentication code/MAC built in that verifies no one tampered with your data. You probably should use a mode of authenticated encryption, preferrably encrypt-then-MAC.

I worry about whether an network eavesdropper could listen in on a session cookie of the django web-server, then use that cookie to log in as the administrator and then get all the users' hashes and decrypt all the information sent over the network that they shouldn't have access to.

I also would be wary of potential replay attacks (add one-time nonces to encrypted requests) or leaking information from the size of the encrypted responses; e.g., if an anonymous person could make a request to the server every day for X's medical records and find by the size of the response that they've visited or not visited recently. Also, I would be wary about where the medical records are going and will they be encrypted at rest on user's hard disks.

I also worry whether you are doing adequate audit logging of who is viewing what medical data and whether that data cannot be easily tampered with.

Not knowing the full details of your scenario and security requirements, I think it may be better to just use TLS (formerly known as SSL) with a secure certificate, plus a well-known utility to provide full disk encryption.

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • Wow, you're background is awesome! Is it okay to pick your brain for a bit? It might take a bit to digest your answer enough to formulate responses. Key for further comments: [myQuestionNumber][yourParagraphNumber] – horriblyUnpythonic Jan 15 '14 at 23:12
  • [0][0] Like my comment on my question, it's just an area of interest. I work for a fairly large company with compliance managers and the like, so if there are any fatal flaws (which I'm sure there will be) they should be exposed. I'd just like to have some plan in place; if nothing else it will show that it has been a concern during development. – horriblyUnpythonic Jan 15 '14 at 23:32
  • [1][3] We have medical records in a database that will be served through Django (Stop me here if this is bad idea in the first place). So if someone has admin access, then they already have access to everything that would be encrypted. The plan is to encrypt before transfer to a user's machine. – horriblyUnpythonic Jan 15 '14 at 23:45
  • As a side note, when I say medical records it's not actual doctor's note from doctor visits. I don't know if there are different tiers of medical information. It's things like height, weight, blood pressure, etc. – horriblyUnpythonic Jan 15 '14 at 23:49
  • [2][1,3] So if I use the django password hash from the auth_user table as a key for AES-CBC then send the salt with the encrypted file I should be fine? Or does simply the accessing the auth_user table create an insecurity (by creating a cookie or something)? – horriblyUnpythonic Jan 16 '14 at 00:00
  • [3][2] Am I wrong in the assumption that if someone tampers with the information it won't decrypt correctly? I was toying with the idea of creating a checksum or hash of the unencrypted file (stop me if that's insecure) and also sending it along with the encrypted file and the salt. – horriblyUnpythonic Jan 16 '14 at 00:04
  • @horriblyUnpythonic - Re: [3][2] - You are wrong in the general case, this is why there's authenticated encryption. Most crypto courses will do a standard example where the message is either "Attack at dawn" or "Attack at dusk". If this was encrypted with AES-CTR you could change XOR the last three bytes with the xor of `awn` and `usk` so the wrong message appears at the other end. (A similar attack works on the first block of AES-CBC by playing with the corresponding bytes of the IV.) – dr jimbob Jan 16 '14 at 06:58
  • A simple checksum is mostly what authenticated encryption provides, but there are many potential flaws you introduce by rolling your own -- e.g., padded oracle attacks. As for levels of protected health information; it definitely depends. Are you employed by a health provider/insurer/business associate covered under HIPAA? Then any personally identifiable health information is covered. See: http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/ . Also, I am not a lawyer, this is not legal advice. – dr jimbob Jan 16 '14 at 07:05