Difference between revisions of "VistA Security"
DavidWhitten (talk | contribs) |
DavidWhitten (talk | contribs) |
||
| Line 6: | Line 6: | ||
"authorize" - permit an action | "authorize" - permit an action | ||
| − | Since the VA uses a "home grown" way of taking human readable text used for each of these and turning it into a non-human undestandable text to be stored in the system, I think it unwise to claim that the VA uses an encryption system. What the VA does use is a obfuscation system, which makes it very difficult for someone to come up with a human readable text to be used for authorization. In my opinion, authentication is a very difficult thing to do with any static system. Dynamic query and response authentication is far more likely to be able to prove identity. | + | The access code is not the password that is chosen by the end user who is providing services for a patient when he/she is using the system. The Access Code (Field #2 in File #200) is chosen by the administrative people who work for the computer group when they add the end user to VistA. |
| + | |||
| + | Normally the verify code is a password that the user decides. In the past, the verify code was set to an empty value, when the access code was set up. To enhance security, the computer group now assigns a temporary value to the Verify Code (Field #11 in File #200). The first time the end user logs into the system, they have to change the verify code to a password that only they know. | ||
| + | |||
| + | The electronic signature is never known by admin staff and is always set by the end user. The admin staff have an option [[OPTION XUSESIG CLEAR|<nowiki>[XUSESIG CLEAR]</nowiki>]] that can be used to clear the electronic signature, should an end user forget it or have problems, but the admin staff cannot see the original electronic signature because it (like the access code and verify code) is stored in an obfuscated way. | ||
| + | |||
| + | Since the VA uses a "home grown" way of taking human readable text used for each of these and turning it into a non-human undestandable text to be stored in the system, [[User:DavidWhitten|I]] think it unwise to claim that the VA uses an encryption system. What the VA does use is a obfuscation system, which makes it very difficult for someone to come up with a human readable text to be used for authorization. In my opinion, authentication is a very difficult thing to do with any static system. Dynamic query and response authentication is far more likely to be able to prove identity. | ||
It would be appropriate for someone who has a VistA system that is actually on the Internet to investigate things like ssl and ssh tunnelling, as they are sub-systems which can support VistA, and which are developed, tested, and investigated by full time security professionals. | It would be appropriate for someone who has a VistA system that is actually on the Internet to investigate things like ssl and ssh tunnelling, as they are sub-systems which can support VistA, and which are developed, tested, and investigated by full time security professionals. | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
Revision as of 14:44, 21 August 2009
Each person who uses the VistA system has an entry in the NEW PERSON File #200. The VistA login security subsystem (XU namespace) requires two passwords (access code and verify code) to authorize someone to use the system, and one password (electronic signature) to allow someone to authorize a different person to proceed with an action.
In English there is a subtle difference "authenticate" - prove identity "authorize" - permit an action
The access code is not the password that is chosen by the end user who is providing services for a patient when he/she is using the system. The Access Code (Field #2 in File #200) is chosen by the administrative people who work for the computer group when they add the end user to VistA.
Normally the verify code is a password that the user decides. In the past, the verify code was set to an empty value, when the access code was set up. To enhance security, the computer group now assigns a temporary value to the Verify Code (Field #11 in File #200). The first time the end user logs into the system, they have to change the verify code to a password that only they know.
The electronic signature is never known by admin staff and is always set by the end user. The admin staff have an option [XUSESIG CLEAR] that can be used to clear the electronic signature, should an end user forget it or have problems, but the admin staff cannot see the original electronic signature because it (like the access code and verify code) is stored in an obfuscated way.
Since the VA uses a "home grown" way of taking human readable text used for each of these and turning it into a non-human undestandable text to be stored in the system, I think it unwise to claim that the VA uses an encryption system. What the VA does use is a obfuscation system, which makes it very difficult for someone to come up with a human readable text to be used for authorization. In my opinion, authentication is a very difficult thing to do with any static system. Dynamic query and response authentication is far more likely to be able to prove identity.
It would be appropriate for someone who has a VistA system that is actually on the Internet to investigate things like ssl and ssh tunnelling, as they are sub-systems which can support VistA, and which are developed, tested, and investigated by full time security professionals.
