Re: Database development plans
In regards to the MD5 fingerprint, would this be a straight MD5 hash, or something like the FreeBSD MD5-based password hash (which I believe supports passwords longer than 8 chars)?
I would certainly expect support for more than 8 characters, like in newer versions of Linux.
Also, would the hash continue to be openly published?
I guess so. Hiding something in the response (by default) has the potential of confusing people while trying to update and/or delete objects. We've been through that already ;-)
It would seem you would still have to deal with potential dictionary attacks.
Correct.
I understand the Perl-based RIPE server would use a "*" in place of the actual crypt-pw and I've been considering adding support for this in IRRd. Also, I would suggest reading the following paper regarding the strength of traditional Unix crypt, FreeBSD's MD5-based crypt, and OpenBSD's Blowfish- based bcrypt -- http://www.usenix.org/events/usenix99/provos.html
Thanks for the pointer!
Regards, Larry Blunk Merit
Regards, Wilfried.
In message <00A08D31.1A9EA894.17@cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACO net" writes:
In regards to the MD5 fingerprint, would this be a straight MD5 hash, or something like the FreeBSD MD5-based password hash (which I believe supports passwords longer than 8 chars)?
I would certainly expect support for more than 8 characters, like in newer versions of Linux.
Also, would the hash continue to be openly published?
I guess so. Hiding something in the response (by default) has the potential of confusing people while trying to update and/or delete objects. We've been through that already ;-)
It would seem you would still have to deal with potential dictionary attacks.
I (as the author of it) would advocate adopting the hash used by FreeBSD as it significantly strengthens the basic MD5 with both a salt and an iterative complexity. It's already used to protect the enable password on all your cisco routers btw. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
participants (2)
-
Poul-Henning Kamp -
Wilfried Woeber, UniVie/ACOnet