| | 368 | |
| | 369 | == Future Direction == |
| | 370 | In-MUMPS encryption can be decrypted by anybody who knows Mumps well enough. Since the application needs to decrypt data for ALL appropriately authorized users, it makes it difficult to design password or token based encryption systems. This is the reason that public/private key encryption will not work smoothly here without compromising security: if you are a different user, how would you decrypt a document encrypted using another user's or a machine's private key? Would you then make a public/private key accessible to everybody? What's the point in that? |
| | 371 | Casting these issues aside, there is one way in which encryption can be strengthened: basing it on a hardware token. You will need one of these for each server, but this ensures that the encrypted data will be unreadable outside the machine at which it was encrypted. |
| | 372 | |
| | 373 | It's best to know what attack vectors to protect against. The biggest security risks are internal. External protection of the entire database can be done using full database encryption. |
| | 374 | |
| | 375 | = Appendix 1: How does TIU encrypt the signature blocks = |
