Steven T. Hatton wrote:
> I understand the business reasoning behind not requiering the default CA > cert store to be password protected, and I understand that they hold > little if any information that is private in nature. OTOH, if someone > can get in and manipulate that store, he or she could put in a trusted > CA for Jolly Roger's rip-off site and then spoof you. Has this > vulnerability been investigated? Unfortunately the vunerablity exists even with password protection on the UI. That's because the information is stored in a database, which can be manipulated directly. The only way around that would be to encrypt the trust data with the PBE, but then you would need the password to *read* the trust data as well (in fact that is how you detect the database was modified, the attacker could not put trust data into the database that does not have the PBE to put the correct trust data in. This would require the supply a password just to connect to an SSL web site! We could sign the trust data with the users private key. That would require the password to modify, but not read the database. The problem is the attacker could replace the signer's certificate, with one he has a private key for, then include his own trust. There is some security derived from this. The user will detect the substitution once he tries to do something with his private key, since his key and cert won't match, but a naive use is still vunerable because he may just assume he has forgotten his password and reset the database. The final result is we cannot provide security under the conditions that the user profile can be compromised. Adding a password gives the user the illusion that we can, exposing him to the potential for attack because he will assume he does not have to protect that resource. bob > > Steven >
