for review password.c and authenticate, was Re: hey

[Luke Kenneth Casson Leighton]

> }> 	net_login_interactive	- uses arc4/oem
> }
> }no, arc4/oem _decrypts_ the NT / LM hash and is nothing to do with the NT
> }/ LM hashes themselves.  once decrypted, you are expected to do a memcmp
> }on the hashes against those in the password database.
> }
> }i _did_ have a function called from net_login_interactive: it is still in
> }BRANCH_NTDOM and has not been transferred to the main branch: one is
> }necessary.
> }
> 
> i know, as usual i over simplify, but the result is the same,
> you have a string, compare f(str) with some stored string.

yep.  except that for your requirements, some sort of lookup index (char
*username, uint32 rid or even a struct smb_passwd) must be passed to the
function as well, such that the lookup is made on the _other_ side of the
password API.
 
> }> so, im my oversimplisticview, if i call my own function to check the passwor
> }d,
> }> there shouldn't be any need for samba to know the nt/lm hash, yes?
> }
> }um... samba does not "know" at the moment, if you consider
> }smb_password_check() to be an entry point in the password database API.
> }
> }so the answer to your question is yes, and being pedantic i would correct
> }you in saying that samba shouldn't need to "know" the nt/lm hash anyway:
> }private/smbpasswd does (as an instance of a password database just like
> }yours), if that makes any sense.
> } 
> }> what gets broken with this approach?
> }
> }which approach?  in this message you haven't described one that i
> }[pedantically] perceive: sorry! 
> 
> i want to keep the 'stored' hashed password out of samba.

as far as i am concerned, the stored hashed password is already out of
samba, on the other side of the password API.  but, reading the paragraph
below, i know now what you mean.

> this is not
> an _iff_ condition. i like to keep the 'secrets' in one place, and not 
> distributed among different data bases - samba/FireWall/Tacacs/Kerberos/Nis 
> etc etc.

good.

> (btw, the host that does the authentication is called 'kots' for 
> Keeper-Of-The-Secrets).

:-)
 
> }
> }> i know that BDC won't work, neither changing password.
> }
> }you mean taking the clear-text password and generating an NT/LM hash?

> yes.

you know the implications of this.  i would like to ensure that this
limitation that you are applying does not limit other password APIs
instances, while still providing code-support for you.  much against my...
searching for appropriate words... sense of clear-cut-designing nature...
not-wishing-to-complicate-things...

i can just see a situation in which other people go "hey, you can support
clear-text passwords in samba!" not realising the security implications of
not allowing trust account passwords to be changed (which are effectively
that passwords are transmitted in the clear).


> }
> }> btw, i almost finished with password/authenticate.
> }
> }excellent.  send a diff -u -w -b -B to jeremy as well, so he can review
> }it too.  and a copy to samba-bugs.
> }
> included at end of message,
> 	1) i moved the relevant stuff out of password.c to authenticate.
> 	2) the smb stuff is not final, pending some chats with luke, (next e-mail 
> soon).
> 
> }btw we found someone else who wants to add a password database (a
> }kerberos-based one).

> great, that makes two of us - strength in numbers :-)

yep: that makes nis+, ldap, kerberos, private/smbpasswd, kots.  any more
for any more? :-)

luke