verify windows password?

[diane]

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

[Arno R]

"diane" <di***********@verizon.netschreef in bericht news:11**********************@p77g2000hsh.googlegr oups.com...

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

What's the use ??
If they are allowed to the program when 'properly' logged on in Windows, then why bother ??
Are you concerned about users using 'other persons' workstation ??
What when they leave the program open when they are gone for lunch ??

The problem is, they can't remember the passwords they've created,

If they can remember the Windows password ... then let the users deal with his/hers password.
I mean: Use the Windows-logon-password in your table and let the user change the password.
(e.g. when they are forced to renew the password.)
But:
What's the use ??

Arno R

[DavidB]

On Jun 11, 1:29 pm, "Arno R" <[e-mail]:

"diane" <[e-mail] in berichtnews:11**********************@p77g2000hsh.g ooglegroups.com...

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

What's the use ??
If they are allowed to the program when 'properly' logged on in Windows, then why bother ??
Are you concerned about users using 'other persons' workstation ??
What when they leave the program open when they are gone for lunch ??

The problem is, they can't remember the passwords they've created,

If they can remember the Windows password ... then let the users deal with his/hers password.
I mean: Use the Windows-logon-password in your table and let the user change the password.
(e.g. when they are forced to renew the password.)
But:
What's the use ??

Arno R- Hide quoted text -

- Show quoted text -

The use seems quite obvius to me. He wants user level security but
wants the password and id for ecah user to be the users windows login
id/password. A rather easy concept IMHO.

[diane]

On Jun 11, 1:29 pm, "Arno R" <[e-mail]:

"diane" <[e-mail] in berichtnews:11**********************@p77g2000hsh.g ooglegroups.com...

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

What's the use ??
If they are allowed to the program when 'properly' logged on in Windows, then why bother ??
Are you concerned about users using 'other persons' workstation ??
What when they leave the program open when they are gone for lunch ??

The problem is, they can't remember the passwords they've created,

If they can remember the Windows password ... then let the users deal with his/hers password.
I mean: Use the Windows-logon-password in your table and let the user change the password.
(e.g. when they are forced to renew the password.)
But:
What's the use ??

Arno R

I am in fact concerned about people using others' workstations--this
is a pretty sensitive application. I am also concerned with
appearance--users feel more confident that an application is secure
when they have to enter a password, and these users pay my
salary! :) But whether of not you think what I want to do is
"useless," what I'm interested in is, can it be done?

[Rick Brandt]

diane wrote:

I am in fact concerned about people using others' workstations--this
is a pretty sensitive application. I am also concerned with
appearance--users feel more confident that an application is secure
when they have to enter a password, and these users pay my
salary! :) But whether of not you think what I want to do is
"useless," what I'm interested in is, can it be done?

It is true that if a user is silly enough to log onto Windows and the
company network and then walk away from their PC that someone else could
walk up to that PC, open your application, and then be able to access stuff
that they should not.

BUT...
Wouldn't a user silly enough to do that also be silly enough to open your
app, log onto it using your home-cooked security, and then walk away from
his PC, creating the exact same situation? I fail to see how adding another
password verification really accomplishes anything beyond just using the
Windows user name that you already have.

Most IT Security people would consider ANYTHING that asks a user for his
Windows password other than the OS itself to be a BIG security problem.
Your application would then be free to do anything with that information.
You are creating a security problem, not solving one if you go this route.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[diane]

It is true that if a user is silly enough to log onto Windows and the

company network and then walk away from their PC that someone else could
walk up to that PC, open your application, and then be able to access stuff
that they should not.

BUT...
Wouldn't a user silly enough to do that also be silly enough to open your
app, log onto it using your home-cooked security, and then walk away from
his PC, creating the exact same situation? I fail to see how adding another
password verification really accomplishes anything beyond just using the
Windows user name that you already have.

Most IT Security people would consider ANYTHING that asks a user for his
Windows password other than the OS itself to be a BIG security problem.
Your application would then be free to do anything with that information.
You are creating a security problem, not solving one if you go this route.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

One, re the "silly user" issue: Our users remain logged in to their
machines all day and are in & out of their offices. I am mostly
concerned with making sure their secretaries or underlings are not
given the opportunity to walk in & open the application and view
sensitive data. My users are sufficiently concerned with the privacy
of this data to make sure that they do not leave the application open
on the desktop when they walk away, and they don't use it every day in
any case.

Two, re Windows security: I'm not trying to GET the users' passwords,
only to verify that they have entered them correctly. Other
applications do this all the time--for example, our third-party IM
client asks for the user's windows password to log in.

Regardless, I feel comfortable with my ability to decide WHAT I want
to do. I'm still looking for help with HOW TO DO IT.

Thank you.

[DavidB]

On Jun 11, 2:12 pm, diane <[e-mail]:

It is true that if a user is silly enough to log onto Windows and the
company network and then walk away from their PC that someone else could
walk up to that PC, open your application, and then be able to access stuff
that they should not.

BUT...
Wouldn't a user silly enough to do that also be silly enough to open your
app, log onto it using your home-cooked security, and then walk away from
his PC, creating the exact same situation? I fail to see how adding another
password verification really accomplishes anything beyond just using the
Windows user name that you already have.

Most IT Security people would consider ANYTHING that asks a user for his
Windows password other than the OS itself to be a BIG security problem.
Your application would then be free to do anything with that information.
You are creating a security problem, not solving one if you go this route.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

One, re the "silly user" issue: Our users remain logged in to their
machines all day and are in & out of their offices. I am mostly
concerned with making sure their secretaries or underlings are not
given the opportunity to walk in & open the application and view
sensitive data. My users are sufficiently concerned with the privacy
of this data to make sure that they do not leave the application open
on the desktop when they walk away, and they don't use it every day in
any case.

Two, re Windows security: I'm not trying to GET the users' passwords,
only to verify that they have entered them correctly. Other
applications do this all the time--for example, our third-party IM
client asks for the user's windows password to log in.

Regardless, I feel comfortable with my ability to decide WHAT I want
to do. I'm still looking for help with HOW TO DO IT.

Thank you.- Hide quoted text -

- Show quoted text -

One could easliy write a routine that closes a database after a given
period of inactivity to resolve the idiot user syndrome...

[Arno R]

"diane" <di***********@verizon.netschreef in bericht news:11**********************@k79g2000hse.googlegr oups.com...

On Jun 11, 1:29 pm, "Arno R" <[e-mail]:

>"diane" <[e-mail] in berichtnews:11**********************@p77g2000hsh.g ooglegroups.com...

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

What's the use ??
If they are allowed to the program when 'properly' logged on in Windows, then why bother ??
Are you concerned about users using 'other persons' workstation ??
What when they leave the program open when they are gone for lunch ??

The problem is, they can't remember the passwords they've created,

If they can remember the Windows password ... then let the users deal with his/hers password.
I mean: Use the Windows-logon-password in your table and let the user change the password.
(e.g. when they are forced to renew the password.)
But:
What's the use ??

Arno R

I am in fact concerned about people using others' workstations--this
is a pretty sensitive application. I am also concerned with
appearance--users feel more confident that an application is secure
when they have to enter a password, and these users pay my
salary! :) But whether of not you think what I want to do is
"useless," what I'm interested in is, can it be done?

Sorry, I did *not* say it is "useless"... but I am very interested in the practical use...

I know for sure that my users *don't* like typing in the same password twice.
That will not give them a feeling of confidence. It wil only annoy them.

But you say you are indeed concerned about people using other's workstations (as I presumed).
I don't know if you can find the API that you are looking for...
But I would take care of my app shutting down after a while of no activity. (Do a Google search for 'idletime')
I would also train the users to close the app when they go to lunch.

And/or use the idea that I gave you in the first place. Let them maintain their own password.

Arno R

[diane]

On Jun 11, 2:49 pm, "Arno R" <[e-mail]:

"diane" <[e-mail] in berichtnews:11**********************@k79g2000hse.g ooglegroups.com...

On Jun 11, 1:29 pm, "Arno R" <[e-mail]:

"diane" <[e-mail] in berichtnews:11**********************@p77g2000hsh.g ooglegroups.com...

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

What's the use ??
If they are allowed to the program when 'properly' logged on in Windows, then why bother ??
Are you concerned about users using 'other persons' workstation ??
What when they leave the program open when they are gone for lunch ??

The problem is, they can't remember the passwords they've created,

If they can remember the Windows password ... then let the users deal with his/hers password.
I mean: Use the Windows-logon-password in your table and let the user change the password.
(e.g. when they are forced to renew the password.)
But:
What's the use ??

Arno R

I am in fact concerned about people using others' workstations--this
is a pretty sensitive application. I am also concerned with
appearance--users feel more confident that an application is secure
when they have to enter a password, and these users pay my
salary! :) But whether of not you think what I want to do is
"useless," what I'm interested in is, can it be done?

Sorry, I did *not* say it is "useless"... but I am very interested in the practical use...

I know for sure that my users *don't* like typing in the same password twice.
That will not give them a feeling of confidence. It wil only annoy them.

But you say you are indeed concerned about people using other's workstations (as I presumed).
I don't know if you can find the API that you are looking for...
But I would take care of my app shutting down after a while of no activity. (Do a Google search for 'idletime')
I would also train the users to close the app when they go to lunch.

And/or use the idea that I gave you in the first place. Let them maintain their own password.

Arno R

I'm not worried about annoying my users. This was actually their
suggestion. If I can't find the appropriate API (it HAS to exist), I
may use your suggestion to capture their windows login in my user
table--but, boy howdy, that seems like a bigger security risk than
just asking Windows to give me a thumbs-up-thumbs-down!

[Arno R]

"diane" <di***********@verizon.netschreef in bericht news:11**********************@q69g2000hsb.googlegr oups.com...

I'm not worried about annoying my users. This was actually their
suggestion. If I can't find the appropriate API (it HAS to exist), I
may use your suggestion to capture their windows login in my user
table--but, boy howdy, that seems like a bigger security risk than
just asking Windows to give me a thumbs-up-thumbs-down!

Yes, it would be a bad idea indeed to save the Windows passwords in an Access table...

However my main idea to solve your initial problem (maintenance) was : Let them maintain their own password!
But since "they can't remember the passwords they've created" this also might not be a real solution...

I just did read your answer to Rick.
==In any case learn them to log off when they leave the office!!
IMO It is plain stupid not to do so, when there is *any* sensitive data on the machine.

But also don't forget about the idletime issue when they are *at* the office....

Arno R

[Rick Brandt]

diane wrote:

I'm not worried about annoying my users. This was actually their
suggestion. If I can't find the appropriate API (it HAS to exist),

There are ways to pass the current user credentials and bounce them off of
an LDAP database to re-authenticate them, but that would just use the
windows credentials that are already in place and accomplishes nothing that
you want.

There is NOT an API that will give your program the user's password and it
should be very obvious why there is not. A password would be pretty useless
if a program running on the PC could just make an API call and get at it
wouldn't you agree?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[diane]

On Jun 11, 3:41 pm, "Rick Brandt" <[e-mail]:

diane wrote:

I'm not worried about annoying my users. This was actually their
suggestion. If I can't find the appropriate API (it HAS to exist),

There are ways to pass the current user credentials and bounce them off of
an LDAP database to re-authenticate them, but that would just use the
windows credentials that are already in place and accomplishes nothing that
you want.

There is NOT an API that will give your program the user's password and it
should be very obvious why there is not. A password would be pretty useless
if a program running on the PC could just make an API call and get at it
wouldn't you agree?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Yes, Rick, I would agree, but I've been very clear that I'm NOT
looking to OBTAIN my users' passwords--I just want windows to give me
a go/no-go on them. I think I've been very, very clear on that, if
you actually read my postings. To clear up any remaining recurring
misconceptions:

1. My users are in & out of their offices all day--trying to get them
to log off every time time they run down the hall is NOT an option.

2. They don't use this app very often or for very long at a time, and
they are very sensitive about its data, so they are NOT likely to
leave the app open (not that that's actually relevant to my question,
but it keeps coming up).

3. My users will NOT be annoyed by having to re-enter their windows
passwords--they've actually ASKED for this feature.

4. Just to reiterate: I am NOT trying to obtain users' Windows
passwords. I want to feed the login name & password to an API which
can tell me yes/no, 0/1, thumbs-up-thumbs-down, go/no-go, let 'em in
or lock 'em out.

I'm hoping for a response from someone who knows how to accomplish
this. As I've said, our third-party IM client accomplishes this--I
want to know HOW.

['69 Camaro]

Hi, Diane.

>Let them maintain their own password.

I'm not worried about annoying my users. This was actually their
suggestion.

Of course the users suggested it. No experienced IT person would ever
suggest compromising Windows security on every Windows computer on the
entire planet by placing the code to check a user's Windows password in an
Access database, where any hacker could copy that code and use it elsewhere
for whatever nefarious deeds he wants.

If I can't find the appropriate API (it HAS to exist)

Fortunately, there's a really, really good reason that you (and hackers)
can't easily find it. It's like handing a loaded gun to a four year old.
The four year old doesn't realize how dangerous it is, and the hacker can
take the gun away from the four year old so quickly and easily that the
loaded gun might as well have been given directly to the hacker.

I
may use your suggestion to capture their windows login in my user
table--but, boy howdy, that seems like a bigger security risk than
just asking Windows to give me a thumbs-up-thumbs-down!

I'm sure hackers are very happy you're so willing to compromise your
organization's Windows' users' passwords (and announce your intentions in
public), but it's far better to compromise the security of your own
organization's network than to compromise the security of all Windows
networks on the planet!

Good luck!
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

[diane]

On Jun 11, 4:10 pm, "'69 Camaro" <ForwardZERO_SPAM.To.
[e-mail]_SPAMwrote:

Hi, Diane.

Let them maintain their own password.

I'm not worried about annoying my users. This was actually their
suggestion.

Of course the users suggested it. No experienced IT person would ever
suggest compromising Windows security on every Windows computer on the
entire planet by placing the code to check a user's Windows password in an
Access database, where any hacker could copy that code and use it elsewhere
for whatever nefarious deeds he wants.

If I can't find the appropriate API (it HAS to exist)

Fortunately, there's a really, really good reason that you (and hackers)
can't easily find it. It's like handing a loaded gun to a four year old.
The four year old doesn't realize how dangerous it is, and the hacker can
take the gun away from the four year old so quickly and easily that the
loaded gun might as well have been given directly to the hacker.

I
may use your suggestion to capture their windows login in my user
table--but, boy howdy, that seems like a bigger security risk than
just asking Windows to give me a thumbs-up-thumbs-down!

I'm sure hackers are very happy you're so willing to compromise your
organization's Windows' users' passwords (and announce your intentions in
public), but it's far better to compromise the security of your own
organization's network than to compromise the security of all Windows
networks on the planet!

Good luck!
Gunny

Seehttp://www.QBuilt.comfor all your database needs.
Seehttp://www.Access.QBuilt.comfor Microsoft Access tips and tutorials.
Blogs:http://www.DataDevilDog.BlogSpot.com...utors2.htmlfor contact
info.

Okay, apparently I've asked this question in the wrong forum. I was
looking for actual technical expertise. I'll look elsewhere.

['69 Camaro]

Hi, Diane.

Okay, apparently I've asked this question in the wrong forum. I was
looking for actual technical expertise. I'll look elsewhere.

No one with the technical expertise is going to be foolish enough to hand it
to you, because you can't protect it from hackers who can use it on _any_
Windows system on the planet to compromise all Windows security, not just
_your_ organization's security.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

[Rick Brandt]

diane wrote:

On Jun 11, 3:41 pm, "Rick Brandt" <[e-mail]:

>diane wrote:

Yes, Rick, I would agree, but I've been very clear that I'm NOT
looking to OBTAIN my users' passwords--I just want windows to give me
a go/no-go on them. I think I've been very, very clear on that, if
you actually read my postings. To clear up any remaining recurring
misconceptions:

1. My users are in & out of their offices all day--trying to get them
to log off every time time they run down the hall is NOT an option.

2. They don't use this app very often or for very long at a time, and
they are very sensitive about its data, so they are NOT likely to
leave the app open (not that that's actually relevant to my question,
but it keeps coming up).

3. My users will NOT be annoyed by having to re-enter their windows
passwords--they've actually ASKED for this feature.

4. Just to reiterate: I am NOT trying to obtain users' Windows
passwords. I want to feed the login name & password to an API which
can tell me yes/no, 0/1, thumbs-up-thumbs-down, go/no-go, let 'em in
or lock 'em out.

I'm hoping for a response from someone who knows how to accomplish
this. As I've said, our third-party IM client accomplishes this--I
want to know HOW.

Okay I think I see now. You want an API call that will cause the *OS* to
prompt the user to re-validate themselves and the API call will pass back to
you whether the credentials it received were good without actually sharing
those credentials with your application.

If there is such an API I have never heard of it.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

['69 Camaro]

Hi, Diane.

4. Just to reiterate: I am NOT trying to obtain users' Windows
passwords. I want to feed the login name & password to an API which
can tell me yes/no, 0/1, thumbs-up-thumbs-down, go/no-go, let 'em in
or lock 'em out.

Let me spell this out for you, because it appears that you don't understand
the consequences of what you're asking for. A hacker doesn't need to know
what the actual Windows password is (although that would obviously be the
quickest way to break into a Windows system). He only needs to know when a
string passed as the password is the correct password. That's when a "brute
force" attack becomes successful. The code you would need to use in your
Access database application to determine whether or not your user's typed in
password matches that user's Windows password is exactly the same code a
hacker would use in a loop to keep trying password combinations until
successful. The hacker can use that same code on your system, and on my
Windows system, and on everyone else's Windows system in a brute force
attack to determine the Windows password of any Windows user on the planet.

With today's fast computer systems, it often only takes seconds or minutes
to try millions or billions of different password combinations
programmatically, whereas a hacker trying to login from outside the system
has a delay of about 20 seconds between tries and usually a maximum number
of tries to successfully authenticate before the system refuses any further
attempts.

Now can you see why no competent IT professional who knows how to do this
would willingly offer you the code in a newsgroup post, even though you,
yourself, may not be planning to use it for some heinous computer crime?

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

[David W. Fenton]

diane <di***********@verizon.netwrote in
news:11*********************@k79g2000hse.googlegro ups.com:

One, re the "silly user" issue: Our users remain logged in to
their machines all day and are in & out of their offices.

This is a domain policy issue. The sysadmin can force those machines
to lock the workstation after inactivity.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.comwrote in
news:9D*****************@newssvr23.news.prodigy.ne t:

Okay I think I see now. You want an API call that will cause the
*OS* to prompt the user to re-validate themselves and the API call
will pass back to you whether the credentials it received were
good without actually sharing those credentials with your
application.

If there is such an API I have never heard of it.

Just set the frigging screen saver to require password
authentication. The result is that the workstation locks when the
screen saver kicks in and can't be unlocked except with the
logged-in user's password (or an adminstrator's username/password).

And this can be set as a system policy, if I'm not mistaken.

Geeze, this stuff is so basic to Windows configuration I can't
beleve nobody knows this stuff.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

diane <di***********@verizon.netwrote in
news:11**********************@q75g2000hsh.googlegr oups.com:

Okay, apparently I've asked this question in the wrong forum. I
was looking for actual technical expertise. I'll look elsewhere.

You're not going to get the answer in a different forum, unless it's
populated by people who don't care about security.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[DavidB]

On Jun 11, 4:22 pm, "'69 Camaro" <ForwardZERO_SPAM.To.
[e-mail]_SPAMwrote:

Hi, Diane.

Okay, apparently I've asked this question in the wrong forum. I was
looking for actual technical expertise. I'll look elsewhere.

No one with the technical expertise is going to be foolish enough to hand it
to you, because you can't protect it from hackers who can use it on _any_
Windows system on the planet to compromise all Windows security, not just
_your_ organization's security.

HTH.
Gunny

Seehttp://www.QBuilt.comfor all your database needs.
Seehttp://www.Access.QBuilt.comfor Microsoft Access tips and tutorials.
Blogs:http://www.DataDevilDog.BlogSpot.com...utors2.htmlfor contact
info.

Gunny you are an ass. You have done nothing but belittle the person
who asked the question because YOU do not understand what was asked!
No one asked for a way to fetch a windows password. The user merely
asked to have the app validate a used based on the windows password.
If you fail to see the difference in that it is simply amazing that
you reached the rank of gunny. Your (totally invalid) point is that
doing so would allow someone to heck into the users computer. Using
that logic, allowing people to log into windows in the firts palce
would be useless since it involves using the windows password in the
exact same manner as the original poster requested. Quit being such a
asswad.

['69 Camaro]

Hi, David.

No one asked for a way to fetch a windows password. The user merely
asked to have the app validate a used based on the windows password.

Neither of you understand the consequences of what she's asking for. She
reiterated that she _doesn't_ want the actual Windows password, but only
wants to determine whether or not the user's typed in password matches the
user's Windows password. If you research brute force attacks, you'll find
that that is exactly what is used to eventually determine a user's password,
but it's placed within a loop where the next possible password combination
is attempted when the previous attempt fails. Handing Diane the code to
check whether or not a possible Windows password combination is correct is
tantamount to handing every hacker in the world the code to determine
anyone's Windows password, because the loop and the code for producing each
possible password combination are trivial.

How many competent IT people are going to do that? None, because they know
why they _shouldn't_, even if they know how. How many incompetent people
are going to do that? None, because although they'd foolishly offer the
solution when asked, they don't know how it's done.

Fortunately, you aren't going to give Diane the answer she seeks. If I were
truly the ass you believe me to be, I'd point out which of these two groups
you are in. Wouldn't I?

If you fail to see the difference in that it is simply amazing that
you reached the rank of Gunny.

I was always told it was because I had far more guts than brains, but the
fact that I was voted unanimously in high school as the student "Most likely
to conquer a small country single-handedly . . . bare-handed, too" may have
had something to do with my future exploits and achievements in the Marine
Corps.

Using
that logic, allowing people to log into windows in the firts palce
would be useless since it involves using the windows password in the
exact same manner as the original poster requested.

There's an important difference, in that Group Policies (for network domain
login rules) and workstation login rules apply for the Windows logins.
These add a sufficient time delay between attempts and limit the maximum
login attempts such that the millions or billions of possible password
combinations (or more) that are required for a brute force attack to succeed
are fairly easily to prevent. Authorized users are allowed to authenticate
at Windows login, whereas brute force attackers aren't. Once authenticated
on a Windows system, a programmatic check of whether or not a possible
password combination matches any user's Windows password could be done
millions of times per minute without the time delay constraint between
attempts, nor the limit on the maximum number of tries of the earlier
Windows login.

By the way, if you ask Dave Hargis, I'm sure he can explain these things to
you better than I can, and in a more pleasant tone than a gunnery sergeant
would.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"DavidB" <je***@yahoo.comwrote in message
news:11**********************@g37g2000prf.googlegr oups.com...

On Jun 11, 4:22 pm, "'69 Camaro" <ForwardZERO_SPAM.To.
[e-mail]_SPAMwrote:

>Hi, Diane.

Okay, apparently I've asked this question in the wrong forum. I was
looking for actual technical expertise. I'll look elsewhere.

No one with the technical expertise is going to be foolish enough to hand
it
to you, because you can't protect it from hackers who can use it on _any_
Windows system on the planet to compromise all Windows security, not just
_your_ organization's security.

HTH.
Gunny

Seehttp://www.QBuilt.comfor all your database needs.
Seehttp://www.Access.QBuilt.comfor Microsoft Access tips and tutorials.
Blogs:http://www.DataDevilDog.BlogSpot.com...utors2.htmlfor
contact
info.

Gunny you are an ass. You have done nothing but belittle the person
who asked the question because YOU do not understand what was asked!
No one asked for a way to fetch a windows password. The user merely
asked to have the app validate a used based on the windows password.
If you fail to see the difference in that it is simply amazing that
you reached the rank of gunny. Your (totally invalid) point is that
doing so would allow someone to heck into the users computer. Using
that logic, allowing people to log into windows in the firts palce
would be useless since it involves using the windows password in the
exact same manner as the original poster requested. Quit being such a
asswad.

[Tim Marshall]

'69 Camaro wrote:

By the way, if you ask Dave Hargis, I'm sure he can explain these things to
you better than I can, and in a more pleasant tone than a gunnery sergeant
would.

Totally OT, but do you know what the equivalent NCO rank in the Canadian
or British army is to a gunnery sergeant? Is that like a regimental
(battalion to you guys) or squadron (company) sergeant major?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

['69 Camaro]

Hi, Tim.

Totally OT, but do you know what the equivalent NCO rank in the Canadian
or British army is to a gunnery sergeant?

According to the NATO ranks, it's equivalent to a Canadian warrant officer
adjutant (OR-7) or British staff sergeant/colour sergeant:

http://en.wikipedia.org/wiki/Ranks_a...rmies_Enlisted

However, since the U.S. Marine Corps has so few commissioned officers, the
Corps is mainly run by the Staff NCO's and NCO's, so a Marine staff sergeant
or gunnery sergeant (both junior Staff NCO's) is generally functionally
equivalent to a company grade officer (commissioned officer from O-1 to O-3)
in any other military service. For example, as a staff sergeant (OR-6 or
E-6), I served as Officer of the Day (OOD) in the base commanding officer's
stead, whereas any other military service requires a minimum O-1 (2nd Lt) to
O-3 (Capt) to stand in for the base commanding officer in his absence.

It's really neat checking into a new unit and finding out that there just
aren't that many people who outrank you, and of those who do, only butter
bars would ever consider messing with a Gunny -- and they learn fairly
quickly what a bad idea that can be. ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

[Matthias Klaey]

diane <di***********@verizon.netwrote:

I've got an application running with table-based security: i capture
the user's windows login with fOsusername, then have them enter a
password checked against their username/login in my own table. The
problem is, they can't remember the passwords they've created, and I
spend more time than I want to resetting.

Here's what I'd LIKE to have happen: when the user opens the
application (Access2k), a dialog box appears with the windows login
name of the currently-logged in user (I can do this part), and they
have to enter their WINDOWS password, which some windows api verifies
for me so I can allow or not allow them in.

Is there a way for windows to verify the password for me? I can't
seem to find anything on this; all I get are directions to
fOsusername, which is only the first half of my battle.

Thanks for any help you can give me.

Hi Diane

Check out the LogonUser API and NetUserChangePassword on

http://search.msdn.microsoft.com/search/

HTH

Matthias Kläy
--
www.kcc.ch

[Lyn]

On Tue, 12 Jun 2007 12:06:02 -0700, '69 Camaro wrote:

>
There's an important difference, in that Group Policies (for network domain
login rules) and workstation login rules apply for the Windows logins.
These add a sufficient time delay between attempts and limit the maximum
login attempts such that the millions or billions of possible password
combinations (or more) that are required for a brute force attack to succeed
are fairly easily to prevent. Authorized users are allowed to authenticate
at Windows login, whereas brute force attackers aren't. Once authenticated
on a Windows system, a programmatic check of whether or not a possible
password combination matches any user's Windows password could be done
millions of times per minute without the time delay constraint between
attempts, nor the limit on the maximum number of tries of the earlier
Windows login.

Hi guys,
I don't want to buy in to the argument -- I am enjoying the exchanges too
much :-)

Just a question. If MS has built in to the Logon API such hacker
deterrents as time delays and maximum attempts, surely that would also
apply if someone were to use the API outside of the Windows OS to
authenticate a user password? So wouldn't it be just as hard to use brute
force in an Access app as it is at the Windows Logon?

Or are we saying that MS have coded their API as a simple authentication
routine, and then built all the hacker proofing around and outside of the
API?

One can never be sure what goes on in the minds of those at MS, and I don't
know the answer to this question, but wouldn't they build all of the
protection INTO the API so that if the method of calling the API fell into
the wrong hands it would remain as safe as it is at Logon time?

Again, I don't know the answer, and I wouldn't like to second-guess MS, but
if I were designing such an API (and I have some experience in specifying
APIs, though not for anything that runs in Windows), I would build in the
protection.

Just a thought...

Cheers,
Lyn.

['69 Camaro]

Hi, Lyn.

If MS has built in to the Logon API such hacker
deterrents as time delays and maximum attempts, surely that would also
apply if someone were to use the API outside of the Windows OS to
authenticate a user password? So wouldn't it be just as hard to use brute
force in an Access app as it is at the Windows Logon?

If the premise is true, then the conclusion is true. That's as much as I'm
willing to say about this Windows feature. (Sorry. I'm not very helpful.)

Or are we saying that MS have coded their API as a simple authentication
routine, and then built all the hacker proofing around and outside of the
API?

One can never be sure what goes on in the minds of those at MS

I'd rather not publicly discuss this feature, because the code needed to
authenticate has certain inherent problems, which of course, have
work-arounds. Just discussing a particular security issue can make the
work-around self-evident.

Again, I don't know the answer, and I wouldn't like to second-guess MS,
but
if I were designing such an API (and I have some experience in specifying
APIs, though not for anything that runs in Windows), I would build in the
protection.

I tend to agree with you, but opposing arguments can also be made in this
situation. If the user has already successfully authenticated into the
network, then why should that user have to wait X number of seconds between
tries and have a limited number of tries when using such an API? And should
the user be automatically logged out and the Network Administrator notified
when the user exceeds this limit after a normal Windows login? If these
last two items are built into the API, then wouldn't the programmer
automatically put "false" for the "logout" and "notify administrator"
parameters of the function? Of course he would, so those wouldn't be
parameters built into the API, but information that would have to be
retrieved from the Group Policy settings, which adds complexity (and time
and cost) to the design of the API function, which may not be desired. It's
a lot easier (and cheaper) to keep it as simple as possible.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

['69 Camaro]

Hi, David.

Gunny you are an ass.
Quit being such a
asswad.

Your vocabulary and grammar are so impressive that perhaps you can help me
identify a word or phrase I'm trying in vain to come up with. What do we
call the guy who logs into Google Groups and marks his own replies with four
stars and marks the replies of other posters in the thread with either one
or two stars (apparently to identify them as "bad answers"), but totally
ignores a helpful answer, as well as the information the questioner gave?

http://groups.google.com/group/comp....6f1500c5177051

Your two replies you marked as so star-worthy totally ignored the following:

1.) Diane's statement that she's saving the User ID's and passwords in a
table (i.e., she's not using User-Level Security, and she never implied that
User-Level Security is one of her goals, either). It's a huge security risk
to save the Windows user names and passwords in a workgroup information file
because very cheap (and free) tools can be used to read the User ID's and
passwords, so it should never be considered as an option.

2.) Diane's statement that "My users are sufficiently concerned with the
privacy of this data to make sure that they do not leave the application
open on the desktop when they walk away," so your suggestion to "write a
routine that closes a database after a given period of inactivity to resolve
the idiot user syndrome" is moot and was ignored by Diane.

3.) Diane is not a "he."

4.) Diane never replied to any of your posts, so she never gave any
indication as to why she would have mysteriously become thrilled enough with
your suggestions to take the time to mark them with four stars, despite the
fact that they didn't address her concerns, nor provide assistance with her
goal.

5.) You didn't even mark Matthias Klaey's helpful reply with any stars,
which conceivably is the only reply Diane received that answered her
question in the way she expected it to be answered. If Diane were to mark
any replies with stars, that's the one she would have picked, although if
you look at her profile and previous posts, you'll see that "measuring other
people and being measured by other people's standards" makes her use of an
online rating system of complete strangers a non sequitur.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.

[Lyn]

On Thu, 14 Jun 2007 12:30:35 -0700, '69 Camaro wrote:

>If MS has built in to the Logon API such hacker
deterrents as time delays and maximum attempts, surely that would also
apply if someone were to use the API outside of the Windows OS to
authenticate a user password? So wouldn't it be just as hard to use brute
force in an Access app as it is at the Windows Logon?

If the premise is true, then the conclusion is true. That's as much as I'm
willing to say about this Windows feature. (Sorry. I'm not very helpful.)

>Or are we saying that MS have coded their API as a simple authentication
routine, and then built all the hacker proofing around and outside of the
API?

One can never be sure what goes on in the minds of those at MS

I'd rather not publicly discuss this feature, because the code needed to
authenticate has certain inherent problems, which of course, have
work-arounds. Just discussing a particular security issue can make the
work-around self-evident.

>Again, I don't know the answer, and I wouldn't like to second-guess MS,
but
if I were designing such an API (and I have some experience in specifying
APIs, though not for anything that runs in Windows), I would build in the
protection.

I tend to agree with you, but opposing arguments can also be made in this
situation. If the user has already successfully authenticated into the
network, then why should that user have to wait X number of seconds between
tries and have a limited number of tries when using such an API? And should
the user be automatically logged out and the Network Administrator notified
when the user exceeds this limit after a normal Windows login? If these
last two items are built into the API, then wouldn't the programmer
automatically put "false" for the "logout" and "notify administrator"
parameters of the function? Of course he would, so those wouldn't be
parameters built into the API, but information that would have to be
retrieved from the Group Policy settings, which adds complexity (and time
and cost) to the design of the API function, which may not be desired. It's
a lot easier (and cheaper) to keep it as simple as possible.

Well, as I said, I don't know much about how this API works. You
apparently do, so I will bow to your insight. 'Nuff said.

Lyn.

[Tim Marshall]

'69 Camaro wrote:

It's really neat checking into a new unit and finding out that there just
aren't that many people who outrank you, and of those who do, only butter
bars would ever consider messing with a Gunny -- and they learn fairly
quickly what a bad idea that can be. ;-)

I could never understand that sort of behaviour - all through officer
school and RMC it was hammered into us that the senior NCOs were to be
respected for their experience and knowledge. Yet so many 2Lts act like
total know-it-all boneheads when they get to their units.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[NeoPa]

See Answer: Verify Windows Password for a potential answer.