Re: On shisa and its password disclosure.
Mats Erik Andersson g...@gisladisker.se writes: Dear all, I am somewhat disturbed by that fact that the superuser is able to execute # shisa -d --keys thereby gaining access to all passwords for all principals of the running KDC. Contrast this to the situation with MIT Kerberos or Heimdal, where a selected administrator is entrusted with the power to inspect such secrecies, which the superuser is unable to access, unless he was able to snoop the administrator's password. Am I lacking some insight, or is there a security issue here? This was a design choice. It may not have been the best one. Storing the password allows some flexibility if crypto parameters needs to be changed later on. The KDC can then recompute the hashed keys. It also allows the same password database to be used by other protocols in the future, that may need access to the raw password. Remember, it should be _possible_ to use the Shishi KDC without storing the password: just convert a password to a key and then store that in the database. So someone genuinely concerned about this should be able to work around it. There ought to be a parameter to shisa, possibly even enabled by default, that forgets the password after generating a key that is stored on disk. This would make it easier to setup a KDC without storing plaintext passwords. Still, I believe it should be possible to use the current approach too: some may want the flexibility gained by storing the plaintext passwords. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shisa and its password disclosure.
Mats Erik Andersson g...@gisladisker.se writes: I am somewhat disturbed by that fact that the superuser is able to execute # shisa -d --keys thereby gaining access to all passwords for all principals of the running KDC. The keys, or the passwords? Not that it probably makes a lot of difference (although only being able to get the keys means that at least it's difficult to attack other realms where the user may reuse the password). Contrast this to the situation with MIT Kerberos or Heimdal, where a selected administrator is entrusted with the power to inspect such secrecies, which the superuser is unable to access, unless he was able to snoop the administrator's password. The superuser on the KDC can similarly retrieve the keys for any principal in the Kerberos KDC with both MIT and Heimdal, using kadmin -l (Heimdal) or kadmin.local (MIT). It's very difficult in a traditional UNIX security model to protect anything against the superuser, of course. If all else fails, one can always just read the disk database files directly. Improved security probably requires eliminating the traditional security model via something like SELinux. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shisa and its password disclosure.
Mats Erik Andersson g...@gisladisker.se writes: The execution of shisa -d --keys u...@ex.org will print the password in clear text, which I find uncomforting. All the more so since it is not at all needed in maintaining the keytab file. I would have expected a dicotomy like used for shadow passwords, where only a string hash is stored, not the plain text string. It's unusual to actually store the passwords, but Active Directory does so as well because it allows you to do several other interesting things: add new enctypes without forcing a password change, and handle authentication methods other than Kerberos where the authentication server has to know the password and not just a precomputed key. There's no real difference in security within a single realm, although it does mean that one can compromise other authentications for the same user if they reuse a password. Executing kadmin.local: getprinc user@SOL will not reveal the clear text password, only basic information about the principal. In my admittedly limited experience with MIT/Solaris, there has never appeared a means for the administrator to make readable any clear text passwords. Is there such a command? MIT and Heimdal don't store the password, so indeed you can't retrieve it. (ktadd in both cases can extract the existing key, however, from which you can authenticate as that user just as if you had the password.) Active Directory stores the password, but you have to have a very high level of access to the LDAP store in order to retrieve it. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
