« Return to Thread: Questions on TroopMaster DotNet Security
Re: Questions on TroopMaster DotNet Security
by Zachary Heaton-2
::
Rate this Message:
On 26 May 2009, at 9:59, NDXhound wrote:
> I have used DotNet for about a year and have been forced to learn
> more about its inner workings than I wanted. I understand your
> concerns. Given the level of security you are suggesting is needed,
> I don't think DotNet will address each point to your satisfaction.
Peter,
Thanks for the reply. I don't necessarily need DotNet to address each
point, I'm just trying to understand the security approach TroopMaster
Software is using. My area of greatest concern is the password
recovery mechanism. Most of my other questions (FTP vs SFTP, server
location, etc.) aren't that important if the data file is securely
encrypted - if the data file is not securely encrypted, then all of
those other concerns become very important.
> I am curious though...when you email your database around do you use
> certificate-base encryption to ensure security?
Partially. Several of the adult leaders (myself included) use
encryption certificates, and one of my medium-term goals is rolling
out a PKI infrastructure with associated Troop e-mail addresses for
all of the adults in the Troop.
> If you use USB keys to move the database around, how do you guard
> against lost keys.
This is a non-issue *if* the data file itself is encrypted. 256-bit
AES with a strong password should be immune to any reasonable degree
of cryptographic attack - the wildcard is the password recovery
mechanism/backdoor which TroopMaster contains. If that can be broken
more cheaply than the data encryption password, then the 256-bit AES
encryption isn't adding anything to the security.
> What about people who use work computers (domain admins know much)?
> What about lost/reclaimed laptops?
Again, neither of these should be huge issues if the data file is
encrypted. [1]
> Are your TM users bonded?
No, but given our youth protection policy (we're chartered to a
Catholic parish) they are all fingerprinted and subject to criminal
background checks, in addition to the BSA background checks.
> Security is always a concern when working with sensitive data. There
> is always room for improvement. In the end it is a risk-reward
> decision balancing the sensitivity of the data with the barriers
> imposed by security measures.
Agreed entirely, and that's why I'm not too worried about elaborate
targeted attacks against our troop computers or about bonding local
TroopMaster users. We don't store personal information on enough
people to make a complicated technical or social attack worthwhile,
and I'm (perhaps optimistically) assuming we don't have much of an
insider threat from Scout parents. The two threats that have me
concerned are:
1.) An attack against the DotNet FTP servers to mass-download
TroopMaster databases stored there. If the FTP passwords are sent
unencrypted, then this is relatively straightforward to do.
2.) An attack against the password recovery function in TroopMaster
which allows the unlocking of all TroopMaster file encryption.
#1 is bad, #2 is very bad, and a combination of #1 and #2 would be
almost unspeakably bad. At this point, the rewards of an attack also
start to become reasonable - instead of getting the personal
information from one Troop, an attacker could get the personal
information from hundreds of troops.
> As an alternative you can eliminate photos, SSN's and drivers
> licence numbers (medical info too) from TM leaving only data that
> could be discovered via Google...or even a trip to Council office
> requesting a Troop roster. This will retain 90% of TM's functionality.
SSNs I'm definitely willing to sacrifice - I'm not certain why that's
marked as a "required" field on the BSA adult application, and frankly
I'm not comfortable storing them. Photos are reasonably easy to
sacrifice, but driver license numbers are painful to lose, given that
they're needed for preparing tour permits.
> Peter
Yours in Scouting,
Zach Heaton
[1] Aside: If the encryption is robust, the only two methods of
attack that come to mind offhand are attacking the encryption password
while it's being entered (e.g., a keystroke logger) or attacking the
encryption password/file contents when they're loaded into RAM
(similar to the Blu-Ray copy protection attacks). Those sorts of
attacks are a concern, but they're difficult to mitigate for any
software, and they assume that the computer reading the TroopMaster
file has already been compromised and is nontrustworthy. For this
reason, I'm not too worried about those sort of attacks.
> I have used DotNet for about a year and have been forced to learn
> more about its inner workings than I wanted. I understand your
> concerns. Given the level of security you are suggesting is needed,
> I don't think DotNet will address each point to your satisfaction.
Peter,
Thanks for the reply. I don't necessarily need DotNet to address each
point, I'm just trying to understand the security approach TroopMaster
Software is using. My area of greatest concern is the password
recovery mechanism. Most of my other questions (FTP vs SFTP, server
location, etc.) aren't that important if the data file is securely
encrypted - if the data file is not securely encrypted, then all of
those other concerns become very important.
> I am curious though...when you email your database around do you use
> certificate-base encryption to ensure security?
Partially. Several of the adult leaders (myself included) use
encryption certificates, and one of my medium-term goals is rolling
out a PKI infrastructure with associated Troop e-mail addresses for
all of the adults in the Troop.
> If you use USB keys to move the database around, how do you guard
> against lost keys.
This is a non-issue *if* the data file itself is encrypted. 256-bit
AES with a strong password should be immune to any reasonable degree
of cryptographic attack - the wildcard is the password recovery
mechanism/backdoor which TroopMaster contains. If that can be broken
more cheaply than the data encryption password, then the 256-bit AES
encryption isn't adding anything to the security.
> What about people who use work computers (domain admins know much)?
> What about lost/reclaimed laptops?
Again, neither of these should be huge issues if the data file is
encrypted. [1]
> Are your TM users bonded?
No, but given our youth protection policy (we're chartered to a
Catholic parish) they are all fingerprinted and subject to criminal
background checks, in addition to the BSA background checks.
> Security is always a concern when working with sensitive data. There
> is always room for improvement. In the end it is a risk-reward
> decision balancing the sensitivity of the data with the barriers
> imposed by security measures.
Agreed entirely, and that's why I'm not too worried about elaborate
targeted attacks against our troop computers or about bonding local
TroopMaster users. We don't store personal information on enough
people to make a complicated technical or social attack worthwhile,
and I'm (perhaps optimistically) assuming we don't have much of an
insider threat from Scout parents. The two threats that have me
concerned are:
1.) An attack against the DotNet FTP servers to mass-download
TroopMaster databases stored there. If the FTP passwords are sent
unencrypted, then this is relatively straightforward to do.
2.) An attack against the password recovery function in TroopMaster
which allows the unlocking of all TroopMaster file encryption.
#1 is bad, #2 is very bad, and a combination of #1 and #2 would be
almost unspeakably bad. At this point, the rewards of an attack also
start to become reasonable - instead of getting the personal
information from one Troop, an attacker could get the personal
information from hundreds of troops.
> As an alternative you can eliminate photos, SSN's and drivers
> licence numbers (medical info too) from TM leaving only data that
> could be discovered via Google...or even a trip to Council office
> requesting a Troop roster. This will retain 90% of TM's functionality.
SSNs I'm definitely willing to sacrifice - I'm not certain why that's
marked as a "required" field on the BSA adult application, and frankly
I'm not comfortable storing them. Photos are reasonably easy to
sacrifice, but driver license numbers are painful to lose, given that
they're needed for preparing tour permits.
> Peter
Yours in Scouting,
Zach Heaton
[1] Aside: If the encryption is robust, the only two methods of
attack that come to mind offhand are attacking the encryption password
while it's being entered (e.g., a keystroke logger) or attacking the
encryption password/file contents when they're loaded into RAM
(similar to the Blu-Ray copy protection attacks). Those sorts of
attacks are a concern, but they're difficult to mitigate for any
software, and they assume that the computer reading the TroopMaster
file has already been compromised and is nontrustworthy. For this
reason, I'm not too worried about those sort of attacks.
« Return to Thread: Questions on TroopMaster DotNet Security
| Free embeddable forum powered by Nabble | Forum Help |
