Bug 72852
| Summary: | mkpasswd does not work with yppasswd | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | akonstam |
| Component: | expect | Assignee: | Miloslav Trmač <mitr> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | akonstam |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-29 13:28:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 141725, 150223 | ||
|
Description
akonstam
2002-08-28 13:30:21 UTC
mkpasswd is totally insecure and should be completely removed from the distribution. I've posted a bug report about this before, but it possibly has been closed WONTFIX or something (I dunno). The program is NOT truely random. It has a period of around 31000, and will only generate about that many random passwords. In a very short period of time, one person on one computer can brute force attack a system which is using mkpasswd to generate passwords. A search of all bugzilla bug reports for "mkpasswd" should turn up my report, and my script of proof for the above statements. Here is the original bug report: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9507 It claims it is fixed now. I don't know what version as it is not indicated. I'll test the latest version however, and see how truely random it is. Havill's expect-5.32.2-random.patch is still in (has been since Jul 19 2001). So perhaps it is better now. I just tested RHL 8.0 mkpasswd and it generated passwords for 2.5 hours in a forkbomb. ;o) It was hard to get out of the accidental forkbomb but I eventually did. ;o) Results: 418260 passwords generated, and 418260 were unique In other words, no password was ever duplicated in over 418260 attempts. I'd have to leave this going all night long to get better testing, but I have a feeling it is much more secure now. Cool. Thank you for your testing. :) Don't suppose it is any better in newer versions of expect? It is frustrating to take so long to get any definitive response for this problem. makpasswd in RH 9 still uses yppasswd as a default with the same problem. However, there is a parameter to change it to use passwd. The locations of passwd and yppasswd are still wrong in the script. With all these changes it still hangs up to 20% of the time in an environment where mkpasswd is in a script that can be run by more than one person and protected by the lockfile command. So mkfile is still a problem. Sorry for leaving this so long. My only concern if that since yp-tools seems to be installed by default, fixing this will break mkpasswd for people not using nis but with yp-tools installed. Perhaps it would be better to have two separate scripts: one for passwd and one for yppasswd? I don't use yppasswd myself, but if you are able to generate a mkyppasswd script I think I can add it to the expect package. I have sent upstream a patch that asks the user for root's password if yppasswd is used. I agree with comment #8 that using yppasswd by default is not desirable, so not fixing the path in mkpasswd is probably better. |