The issue isn't with certificates; it is with private keys. You are right that private keys stored in files and protected by passwords can be attacked with dictionary attacks, rainbow tables, guessing, etc. The traditional counter-measure is to store the private-key in a FIPS 140-2 Level 2/3 certified hardware token that will not give up the private-key, and can lock up after some configurable number of incorrect password attempts.
NSS is capable of working with many such hardware tokens with just a few minutes of configuration work. It is much easier in Windows than Linux/Solaris/etc., but there are tokens and drivers for other platforms too. The certificates itself can be stored anywhere, since they do not contain any secrets - local files, LDAP, etc. - whatever works for you. Arshad Noor StrongAuth, Inc. D3|\||\|!$ wrote: > Hi all!!! > > I'm developing a client-server application in which I wish to make the > certificate database on the client side discreet....I'm skeptical of > leaving the cert8.db, secmod.db, and key3.db accessible to all & > sundry....Makes it vulnerable to getting hacked... I fully understand > that the files are password protected but I still have my doubts > regarding the password security...What if one could simply make copies > of the files, modify the certutil.exe code to work as a brute force > password cracker & LO!!!.... I guess we can easily crack atleast the > ones having WEAK PASSWORDS.... > > So could anybody suggest me links to the certificate management > mechanisms being used with Firefox, thunderbird, openOffice(I believe > that these use NSS, right???), etc so that I may learn something from > them....??? > > Are there any workarounds for the neccessity of local certificate > databases...???? Can I not perhaps, allow the client to querry a > remote certificate database like we do for CRLs?? > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
