Re: Validate user/pass with Windows accounts

From: Etienne Charland (mystery@golden.net)
Date: 04/24/03


From: "Etienne Charland" <mystery@golden.net>
Date: Thu, 24 Apr 2003 11:40:28 -0400


Why I don't use standard NT authentication mecanism? Well, there are a few
reasons (I'm using it to secure Remoting communications)
1) Those can only be used with Windows accounts, so the program looses
control over logins.
2) NTLM's challenge/response can be cracked by someone grabbing the
challenge and the response. They can brute-force until they find the right
password.
3) NT security haven't been designed for Remoting. I'm not even sure if SSL
works with Remoting when async requests come in the wrong order, or when
using custom channels where requests can get droped like UDP.

But thinking about it, it shouldn't be a problem passing the password simply
encrypted over the wire. What's important is to only store a hash. However,
there is only a little problem: the cracker will have a clue for the
password's length. If the encrypted data takes 16 bytes, the password isn't
bigger than 16 chars. Otherwise, the password is bigger. But I don't think
it is really an issue.

"Daniel Pravat [MSFT]" <dpravat@online.microsoft.com> wrote in message
news:uxsVI5iCDHA.33548@TK2MSFTNGP10.phx.gbl...
> Why you will need a custom authentication mechanism ? Pick one tested
> in real word, exposed by NT Security .
> You can use the standard mechanism used by NT of using SSPI dance between
> machines at the end you will have a brand new session the server side,
ready
> to use. You should look into
IntializeSecurityContext/AcceptSecurityContext
> (not sure if they are exposed by .NET framework)
>
> BTW, there is not such a big difference between passing the hash and
passing
> the password.
> You are at risk of loosing the hash and remember, one way to discover the
> user passwords
> is to do brute force attack against the hash, "accessible" for admins.
>
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Etienne Charland" <mystery@golden.net> wrote in message
> news:u79ndYfCDHA.2044@TK2MSFTNGP10.phx.gbl...
> > hum... so... I have to pass the plain-text password?? That's kind of a
> > problem... since I only pass a hash over the network. I've made my
> > customizable authentication protocol. I could pass the password
> plain-text,
> > since it's encrypted anyway. However, I still don't like the idea of
> passing
> > full passwords over the wire... Is there a way to validate from the
hash?
> >
> > Thanks
> >
> > Etienne
> >
> > "Daniel Pravat [MSFT]" <dpravat@online.microsoft.com> wrote in message
> > news:#s6VFvbCDHA.2296@TK2MSFTNGP10.phx.gbl...
> > > You must ask the system to validate the credential for you.
> > >
> > > See LongonUser for local/domain user :
> > > [DllImport("advapi32.dll", SetLastError=true)]
> > > public static extern bool LogonUser(String lpszUsername, String
> > lpszDomain,
> > > String lpszPassword,
> > > int dwLogonType, int dwLogonProvider, ref IntPtr phToken);
> > >
> > > For a remote user you need to investigate network authentication
family
> of
> > > functions assuming the remote
> > > machine is configured to accept remote connections.
> > >
> > > --
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > Use of included script samples are subject to the terms specified at
> > > http://www.microsoft.com/info/cpyright.htm
> > >
> > >
> > > "Etienne Charland" <mystery@golden.net> wrote in message
> > > news:upRdDVUCDHA.33376@TK2MSFTNGP10.phx.gbl...
> > > > Let's say I have the username "Joe" and the password "abc", how can
I
> > > check
> > > > wether it's the right password for that Windows account? All I know
is
> > > that
> > > > Windows doesn't store "abc" but only a hash of it. So I would have
to
> > > > compare hashes in some way... Any hint?
> > > >
> > > > Thanks!
> > > >
> > > > Etienne
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Relevant Pages