Hello again -
Well, after a bit more experimentation, I think I've managed to answer my own
question (reproduced below).
The nub of the problem is that there are (at least) two encryption algorithms
available under DU4.0D. One of them is used by crypt() and bigcrypt(), and the
other is used by crypt16(). Which one is required to match a particular user's
encrypted password is indicated by the value of u_oldcrypt in the
authorisation file. (0 for crypt/bigcrypt style, 1 for crypt16 style).
However, there's also a call dispcrypt(), which takes a third argument which
specifies the encryption algorithm to use (which can be taken directly from
the value of u_oldcrypt). So unless anyone knows a reason why this is a bad
idea, that's what I'll use in future.
Richard
On Tue, 16 Jun 1998 14:04:20 +0100 Richard Rogers <R.M.Rogers_at_staffs.ac.uk>
wrote:
> Hi -
>
> I've just converted my authorization database to auth.db format on a
> development system (better late than never, but it does mean big changes to
> our account creation scripts), and consequently had to change a daemon from
> using getprpwnam() to the new getespwnam(). While I was doing this, it seemed
> to make sense to migrate from the old undocumented bigcrypt() call to the
> newer, documented crypt16(). However, I am unable to get this to work as
> expected. Even short (<= 8 character) passwords are encrypted to a 24 (?)
> character string, and neither they nor genuinely "long" passwords encrypt
> successfully to the encrypted password stored in the auth database. For short
> passwords, crypt() still works, and for either long or short passwords,
> bigcrypt() still works.
>
> Am I missing something here, or is something broken?
-----------------------------------
Richard Rogers
Information Technology Services
Staffordshire University
Tel: 01785 (+44 1785) 353395
E-mail: R.M.Rogers_at_staffs.ac.uk
...Who knows where the time goes?...
Received on Wed Jun 17 1998 - 13:28:18 NZST