for review password.c and authenticate, was Re: hey
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Wed Jun 3 14:55:46 GMT 1998
> }> 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
> 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
> }> so, im my oversimplisticview, if i call my own function to check the passwor
> }> 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.
> (btw, the host that does the authentication is called 'kots' for
> }> i know that BDC won't work, neither changing password.
> }you mean taking the clear-text password and generating an NT/LM hash?
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...
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
> }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? :-)
More information about the samba-technical