> From: Brian Candler <[EMAIL PROTECTED]> > On Wed, Feb 19, 2003 at 09:54:32PM -0800, John Rudd wrote: > > 1) the keys are encrypted in the KDC, not plain text > > > > 2) the mechanism is 'shared secret' based > > If I understand correctly, physical access to the KDC is sufficient to break > all user accounts. > > In other words, the shared secret material on the KDC disks is equivalent to > cleartext passwords - take a copy of those disks and you can impersonate any > user. > > Or has that been changed in a new version of Kerberos? I would be interested > to know how. >
It's not "sufficient to break all accounts". You still have to do more, depending upon the setup of the KDC. 1) most KDC's "cheat" for convenience sake. When you start the KDC, you have to tell the process what the master key is. That means either starting it by hand, or having a "stash file" (a copy of the master key, somewhere out on the disk). And, of course, the kdc.conf file says right where that stash file is. So, a casual adversary wont know, but an informed one will. And if you just happen to get a copy of the database, then it wont be in a plainly readable form (for example, if you keep the stash file on a different volume than the database, and you keep the backups of the volumes upon different tapes, then it's not necessarily catastrophic if the tape with the database falls into the wrong hands ... but if that does happen, you should re-encrypt the database with a new master key (which you should also do when there's a change in personelle for the people who know the master key) ... and then it's probably also a good idea to force everyone to change their passwords) 2) if you've got a propperly secured KDC, then the person who breaks in to it is probably going to be someone who is somewhat knowledgable with cryptography. Thus, they could take an encrypted database and run a good solid cryptographic attack upon its contents (or even a brute force one). Given the reality of cryptography, nothing that is encrypted is "100% secure", it's "secure for as long as it will withstand a brute force attack". Given a determined and informed attacker, any encrypted material is only secure for a certain amount of time (which is one of the reasons why password aging is always recommended -- hopefully you'll change your passwords faster than the amount of time it would take a determined brute force attack to decrypt it, whether it's a brute force attack on a unix password or a brute force attack upon an encrypted kerberos ticket; as long as you keep changing the password often enough, then the brute force attacker will probably have obsolete data when his attack is finished, and then he'll have to start his attack all over again ... and hopefully you will have changed passwords again before that's finished, again). 3) there is a wrinkle in there about how the primary kdc communicates with the secondary kdc's, but I'm not sure what that is. So, it's not that the person who breaks in suddenly has all of the jewels, it's that he's now able to take the safe with him and work directly with it at home (and if he knows what he's doing, he may even know where you've kept the combination to the safe). But, because the database isn't plain text, but encrypted, it helps with securing things like backups. (I think one person told me you might want to even store the stash file on a volume that isn't being backed up ... if the volume gets corrupted, you'll replace the stash file from knowing the master key's pass phrase, instead of having it on a tape) Or, if you're REALLY paranoid, and don't mind cumbersome restarts (and hopefully you don't have to restart often), then you don't keep a stash file at all. You always restart the KDC by hand. If you don't have a stash file, then, no, direct access to the KDC is not sufficient to accessing all of the data in the database. They'll then have to run some form of cryptographic attack upon the database. Hopefully, before that's done, you'll have detected the fingerprints of the intrusion, changed your master key, and forced all of the other keys to be updated (force user passwords to change, and go out to change the host tickets by hand). ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
