From: Les B. <le...@le...> - 2003-03-02 00:10:13
|
Craig White <cra...@az...> wrote: >> Actually, I think that ClarkConnect is based up RedHat and I think that Redhat doesn't typically include MD5 encryption for users/passwords but that doesn't mean that the passwords aren't encrypted. I am under the impression that MD5 is getting a bit long in the tooth and not the strongest of encryption methods. << Red Hat uses MD5 and shadow passwords by default, and has for some years now. Or at least, what *feels* like years. MD5 might be long in the tooth at just over ten years old, but its mathematical basis is sound and it still remains "computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest". If MD5 ever starts to become problematical, a switch to SHA-1 would be trivial. >> As for ClarkConnect 'being a complete distro,' I would have to guess that everybody's definition of what represents a complete distro is going to differ anyway. It obviously is complete enough for the function it is to provide, can tie into a larger frame of authenticaion methods such as NIS and will accept the installation of binaries to extend it's functionality. That seems fairly complete to me. << Adding software development tools like GCC to a firewall is not to complete it, it is going to *reduce* security, as it makes it possible for a threat agent to install rootkits and other tools from source. In fact, a comprehensive organizational security policy will usually not permit compilers on production systems of any kind, let alone firewalls. I certainly wouldn't allow NIS on a firewall; there are simply too many vulnerabilities - both known, and on the balance of probabilities, unknown - in NIS itself and the underlying RPC/portmapper subsystems. NIS+ is better, but I wouldn't allow even that. In any case, a firewall probably should not participate in any distributed authentication scheme, except for road warriors who need to poke holes in it - and even that is better done using a VPN scheme with hardware tokens, RSA ACE server, or X.509 certificates. The inability to compile on firewall machines causes one problem - it makes it difficult to install Net::SSLeay and thereby secure Webmin. On my 'to-do' list I have an item for building an RPM of Net::SSLeay, but it's a long way down the list at the moment. Of course, for some people, even running Webmin with SSL support is an unacceptable risk. Where I *do* allow it, Webmin binds only to the internal interface of the firewall. Best, --- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] |