Message-ID: <SIMEON.980618092921.B_at_richard_rogers.staffs.ac.uk>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a7p Build (10)
MIME-Version: 1.0
Content-Type: Text/PLAIN; CHARSET=US-ASCII
Hello again -
I hope this will be the "definitive" answer to this problem (for now at
least).
Following my original summary on this subject, John Ferlan
(ferlan_at_zk3.dec.com) has pointed out that the "right" way to do this is to use
the sia_validate_user() call. This provides a level of abstraction, so that
you don't need to know about how passwords are stored or encrypted - it will
work in BASE or ENHANCED security modes, and irrespective of the encryption
algorithm used. I've given it a brief try-out, and it it does seem to work as
advertised, and it does simplify the coding process as you don't need to deal directly
with the authorisation-related data structures and encryption routines - just feed it the
username and password (plus one or two other minor items), and it will return a success or
failure code. The only drawback I can see is that my sialog files are going to grow a lot
quicker from now on! So it looks like this is the right way to go...but hey, I've had an
interesting detour ;-)
John's message and my earlier summary are reproduced in full below.
On Wed, 17 Jun 1998 10:06:49 -0400 John Ferlan <ferlan_at_zk3.dec.com> wrote:
> What you're doing works - but you have to ask yourself why are you doing it? You
> are making a dependancy then on some particular format when determining whether a
> user typed the correct pass phrase... and you then have to know the format of the
> db - what if it changes again (not that I'm saying it's going to...)?
>
> Check out App. D of the Security Manual - there's a coding example there that uses
> sia_ses_reauthent which will work regardless of what format the password is stored
> as... there's also a sia_validate_user routine that would do what I'm guessing
> you're doing - validating in your application that some user is who they say they
> are and that they have the right pass phrase. The sia routines will take care of
> the prompting for you as well - and they work whether you have Base or Enhanced or
> DCE or Pathworks or "anything that comes in the future"...
>
>
> .......................
>
>
> Richard Rogers wrote:
>
> > 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?...
>
>
>
> --
>
> John Ferlan | DTN: 264-0854 Office: ZKO3-3/Y26
> ferlan aT zk3 dOt dec dOt com | Digital Equipment Corp
> To reply read above and figure it out_at_ | 110 Spit Brook Rd.
> | M/S: ZKO3-3/W20
> Spammers can cheerfully send mail to: | Nashua, NH 03062-2698
> uce_at_ftc.gov | (603)884-0854
> root_at_localhost
> webmaster_at_localhost
> postmaster_at_localhost
>
>
-----------------------------------
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 Thu Jun 18 1998 - 10:30:53 NZST