Storing password issue 
Author Message
 Storing password issue

This is an issue which I'll have to deal with in a week or two,
so I'm trying to get a head start on it.

I have a .VBS script which brings up IE
(set IE = CreateObject("InternetExplorer.Application"), loads a
page (think credit card payment page), and then fills out the login
form.  Everything is working, but I am intensely displeased at
having my password visible within the .vbs file, although I like
everything else being visible.  So, in particular, it doesn't bother
me that someone could come along and edit or run the file (I assume
I'll have some protection scheme for that), but it does bother me that
they could look inside the file and actually know my password.

    Here's what I imagine the goal to be (and please feel free to
comment about the goal itself, taking into account my motivations):
I want the script to be viewable, but I don't want the password
to be viewable.
    So my first idea was, I'll have a key in the place of the password.
Where "myPassword1" appears, when the time comes to stuff the
password field (I will have ahold of the actual <INPUT type=password ...>
object and will just set its .value attribute), I would do some kind
of a lookup within some imagined windows cache of passwords
using "myPassword1" as the key.
    But I don't like this idea because if it's a "standard windows lookup
scheme", then knowing the key would be tantamount to knowing the
password (Ie. someone else could write a program stub to get the password).
I would have to grow my own encryption / lookup scheme, which
I could do, but it's something I'd like to avoid (and I'm sure my
issues have been addressed 1000s of time over).
     So maybe windows has a standard scheme where it would transfer
a "looked up password" directly to the <INPUT type=password ...> object
without giving any other prying software a chance to look at it.

    The end goal of all this is that eventually, the .VBS files will reside
on clients' systems (or I might want to publish a script without
accidentally revealing a password, or demo my software and
safely show the file to a client), and the script will be run on an
automated basis.  (For example, a script to clean out the spam
in my yahoo mailbox involves logging in to yahoo)

    So on the one hand, having a .vbs file which logs in (regardless
of password management scheme) to some page exposes that
account to abuse/exploit.  On the other hand, automated systmes
require password management.  I am trying to find myself between
these two poles.  For the nonce, I'd prefer small and practical.
I'm open to all comments - this is more of a "getting the creative
juices flowing" kind of post rather than a "backed my way into a
corner, looking for a way out" post.

    Regards from New York City, where it's finally sunny after a week of rain,
    Csaba Gabor

PS.  encrypting the .VBS file itself is not viable for a solution (it can
be an additional measure).  Even if it was secure, it obscures the
original .vbs file, which I don't want to be required.



Sat, 19 Nov 2005 00:03:53 GMT  
 Storing password issue
First of all, you should NEVER , EVER have a password inside a vbs file even
if you're planning to encrypt it
Second, if you want to handle password fields you should have this done on
the Server side, not the client side, (your vbs is, and Runs on the server)
because no matter What you do, your client can edit the VBS file or Debug it
and just dump out the password in plain text, and you don't want that to
happen

So,
a) Never have a password in a script (client or server side)
b) Never have password handling script running on your client
c) make sure you secure your password handling script on your server with
the right Acls's

--
===========================================================
This posting is provided "AS IS" with no warranties and confers no rights
===========================================================


Quote:
> This is an issue which I'll have to deal with in a week or two,
> so I'm trying to get a head start on it.

> I have a .VBS script which brings up IE
> (set IE = CreateObject("InternetExplorer.Application"), loads a
> page (think credit card payment page), and then fills out the login
> form.  Everything is working, but I am intensely displeased at
> having my password visible within the .vbs file, although I like
> everything else being visible.  So, in particular, it doesn't bother
> me that someone could come along and edit or run the file (I assume
> I'll have some protection scheme for that), but it does bother me that
> they could look inside the file and actually know my password.

>     Here's what I imagine the goal to be (and please feel free to
> comment about the goal itself, taking into account my motivations):
> I want the script to be viewable, but I don't want the password
> to be viewable.
>     So my first idea was, I'll have a key in the place of the password.
> Where "myPassword1" appears, when the time comes to stuff the
> password field (I will have ahold of the actual <INPUT type=password ...>
> object and will just set its .value attribute), I would do some kind
> of a lookup within some imagined windows cache of passwords
> using "myPassword1" as the key.
>     But I don't like this idea because if it's a "standard windows lookup
> scheme", then knowing the key would be tantamount to knowing the
> password (Ie. someone else could write a program stub to get the
password).
> I would have to grow my own encryption / lookup scheme, which
> I could do, but it's something I'd like to avoid (and I'm sure my
> issues have been addressed 1000s of time over).
>      So maybe windows has a standard scheme where it would transfer
> a "looked up password" directly to the <INPUT type=password ...> object
> without giving any other prying software a chance to look at it.

>     The end goal of all this is that eventually, the .VBS files will
reside
> on clients' systems (or I might want to publish a script without
> accidentally revealing a password, or demo my software and
> safely show the file to a client), and the script will be run on an
> automated basis.  (For example, a script to clean out the spam
> in my yahoo mailbox involves logging in to yahoo)

>     So on the one hand, having a .vbs file which logs in (regardless
> of password management scheme) to some page exposes that
> account to abuse/exploit.  On the other hand, automated systmes
> require password management.  I am trying to find myself between
> these two poles.  For the nonce, I'd prefer small and practical.
> I'm open to all comments - this is more of a "getting the creative
> juices flowing" kind of post rather than a "backed my way into a
> corner, looking for a way out" post.

>     Regards from New York City, where it's finally sunny after a week of
rain,
>     Csaba Gabor

> PS.  encrypting the .VBS file itself is not viable for a solution (it can
> be an additional measure).  Even if it was secure, it obscures the
> original .vbs file, which I don't want to be required.



Sat, 19 Nov 2005 03:29:46 GMT  
 Storing password issue
Hi Sam,

    Thanks for your response.  I agree with you on point a (and the part
leading up to it).  That was the reason for the post.  Except perhaps
I have not been clear enough on my utility.  It has nothing
to do with the [web page] server side.  And by client I was meaning
customer.

    So this little utility takes directives to muck about with web pages.
For example, I will pay my credit card bill online once a month.
So once a month, my .VBS utility fires up, loads up the OCX that
does most of the work, and proceeds to issue a set of directives
(residing in the .VBS file) to IE that are something like:

"Navigate to Credit card home page"
"Enter username: myUserName"
"Enter password: myPassword"
"Click on the Log On button"
...

    Perhaps this alters the remainder of the conclusions.
    Csaba


Quote:
> First of all, you should NEVER , EVER have a password inside a vbs file even
> if you're planning to encrypt it
> Second, if you want to handle password fields you should have this done on
> the Server side, not the client side, (your vbs is, and Runs on the server)
> because no matter What you do, your client can edit the VBS file or Debug it
> and just dump out the password in plain text, and you don't want that to
> happen

> So,
> a) Never have a password in a script (client or server side)
> b) Never have password handling script running on your client
> c) make sure you secure your password handling script on your server with
> the right Acls's

> --
> ===========================================================
> This posting is provided "AS IS" with no warranties and confers no rights
> ===========================================================



> > This is an issue which I'll have to deal with in a week or two,
> > so I'm trying to get a head start on it.

> > I have a .VBS script which brings up IE
> > (set IE = CreateObject("InternetExplorer.Application"), loads a
> > page (think credit card payment page), and then fills out the login
> > form.  Everything is working, but I am intensely displeased at
> > having my password visible within the .vbs file, although I like
> > everything else being visible.  So, in particular, it doesn't bother
> > me that someone could come along and edit or run the file (I assume
> > I'll have some protection scheme for that), but it does bother me that
> > they could look inside the file and actually know my password.

> >     Here's what I imagine the goal to be (and please feel free to
> > comment about the goal itself, taking into account my motivations):
> > I want the script to be viewable, but I don't want the password
> > to be viewable.
> >     So my first idea was, I'll have a key in the place of the password.
> > Where "myPassword1" appears, when the time comes to stuff the
> > password field (I will have ahold of the actual <INPUT type=password ...>
> > object and will just set its .value attribute), I would do some kind
> > of a lookup within some imagined windows cache of passwords
> > using "myPassword1" as the key.
> >     But I don't like this idea because if it's a "standard windows lookup
> > scheme", then knowing the key would be tantamount to knowing the
> > password (Ie. someone else could write a program stub to get the
> password).
> > I would have to grow my own encryption / lookup scheme, which
> > I could do, but it's something I'd like to avoid (and I'm sure my
> > issues have been addressed 1000s of time over).
> >      So maybe windows has a standard scheme where it would transfer
> > a "looked up password" directly to the <INPUT type=password ...> object
> > without giving any other prying software a chance to look at it.

> >     The end goal of all this is that eventually, the .VBS files will
> reside
> > on clients' systems (or I might want to publish a script without
> > accidentally revealing a password, or demo my software and
> > safely show the file to a client), and the script will be run on an
> > automated basis.  (For example, a script to clean out the spam
> > in my yahoo mailbox involves logging in to yahoo)

> >     So on the one hand, having a .vbs file which logs in (regardless
> > of password management scheme) to some page exposes that
> > account to abuse/exploit.  On the other hand, automated systmes
> > require password management.  I am trying to find myself between
> > these two poles.  For the nonce, I'd prefer small and practical.
> > I'm open to all comments - this is more of a "getting the creative
> > juices flowing" kind of post rather than a "backed my way into a
> > corner, looking for a way out" post.

> >     Regards from New York City, where it's finally sunny after a week of
> rain,
> >     Csaba Gabor

> > PS.  encrypting the .VBS file itself is not viable for a solution (it can
> > be an additional measure).  Even if it was secure, it obscures the
> > original .vbs file, which I don't want to be required.



Sat, 19 Nov 2005 05:00:13 GMT  
 Storing password issue
how about creating a COM object to store your Passwords in LSA and retrieve
it from over there
Another choice would be to have your COM object use DPAPI's to encrypt and
decrypt the secret information

--
===========================================================
This posting is provided "AS IS" with no warranties and confers no rights
===========================================================


Quote:
> Hi Sam,

>     Thanks for your response.  I agree with you on point a (and the part
> leading up to it).  That was the reason for the post.  Except perhaps
> I have not been clear enough on my utility.  It has nothing
> to do with the [web page] server side.  And by client I was meaning
> customer.

>     So this little utility takes directives to muck about with web pages.
> For example, I will pay my credit card bill online once a month.
> So once a month, my .VBS utility fires up, loads up the OCX that
> does most of the work, and proceeds to issue a set of directives
> (residing in the .VBS file) to IE that are something like:

> "Navigate to Credit card home page"
> "Enter username: myUserName"
> "Enter password: myPassword"
> "Click on the Log On button"
> ...

>     Perhaps this alters the remainder of the conclusions.
>     Csaba




- Show quoted text -

Quote:
> > First of all, you should NEVER , EVER have a password inside a vbs file
even
> > if you're planning to encrypt it
> > Second, if you want to handle password fields you should have this done
on
> > the Server side, not the client side, (your vbs is, and Runs on the
server)
> > because no matter What you do, your client can edit the VBS file or
Debug it
> > and just dump out the password in plain text, and you don't want that to
> > happen

> > So,
> > a) Never have a password in a script (client or server side)
> > b) Never have password handling script running on your client
> > c) make sure you secure your password handling script on your server
with
> > the right Acls's

> > --
> > ===========================================================
> > This posting is provided "AS IS" with no warranties and confers no
rights
> > ===========================================================



> > > This is an issue which I'll have to deal with in a week or two,
> > > so I'm trying to get a head start on it.

> > > I have a .VBS script which brings up IE
> > > (set IE = CreateObject("InternetExplorer.Application"), loads a
> > > page (think credit card payment page), and then fills out the login
> > > form.  Everything is working, but I am intensely displeased at
> > > having my password visible within the .vbs file, although I like
> > > everything else being visible.  So, in particular, it doesn't bother
> > > me that someone could come along and edit or run the file (I assume
> > > I'll have some protection scheme for that), but it does bother me that
> > > they could look inside the file and actually know my password.

> > >     Here's what I imagine the goal to be (and please feel free to
> > > comment about the goal itself, taking into account my motivations):
> > > I want the script to be viewable, but I don't want the password
> > > to be viewable.
> > >     So my first idea was, I'll have a key in the place of the
password.
> > > Where "myPassword1" appears, when the time comes to stuff the
> > > password field (I will have ahold of the actual <INPUT type=password
...>
> > > object and will just set its .value attribute), I would do some kind
> > > of a lookup within some imagined windows cache of passwords
> > > using "myPassword1" as the key.
> > >     But I don't like this idea because if it's a "standard windows
lookup
> > > scheme", then knowing the key would be tantamount to knowing the
> > > password (Ie. someone else could write a program stub to get the
> > password).
> > > I would have to grow my own encryption / lookup scheme, which
> > > I could do, but it's something I'd like to avoid (and I'm sure my
> > > issues have been addressed 1000s of time over).
> > >      So maybe windows has a standard scheme where it would transfer
> > > a "looked up password" directly to the <INPUT type=password ...>
object
> > > without giving any other prying software a chance to look at it.

> > >     The end goal of all this is that eventually, the .VBS files will
> > reside
> > > on clients' systems (or I might want to publish a script without
> > > accidentally revealing a password, or demo my software and
> > > safely show the file to a client), and the script will be run on an
> > > automated basis.  (For example, a script to clean out the spam
> > > in my yahoo mailbox involves logging in to yahoo)

> > >     So on the one hand, having a .vbs file which logs in (regardless
> > > of password management scheme) to some page exposes that
> > > account to abuse/exploit.  On the other hand, automated systmes
> > > require password management.  I am trying to find myself between
> > > these two poles.  For the nonce, I'd prefer small and practical.
> > > I'm open to all comments - this is more of a "getting the creative
> > > juices flowing" kind of post rather than a "backed my way into a
> > > corner, looking for a way out" post.

> > >     Regards from New York City, where it's finally sunny after a week
of
> > rain,
> > >     Csaba Gabor

> > > PS.  encrypting the .VBS file itself is not viable for a solution (it
can
> > > be an additional measure).  Even if it was secure, it obscures the
> > > original .vbs file, which I don't want to be required.



Sat, 19 Nov 2005 07:22:37 GMT  
 Storing password issue
Hi Sam, this is more along the line of what I was thinking.  If I understand you
right, by suggesting that I create a COM object, you imply that Windows doesn't
provide me a standard package addressing my password wants.

I'm generally understanding most concepts, but I'm somewhat weak on TLAs.
Would you mind filling me in on what LSA is.

Thanks,
Csaba

TLA = Three Letter Acronym

 - so you are saying
that W

Quote:
> how about creating a COM object to store your Passwords in LSA and retrieve
> it from over there
> Another choice would be to have your COM object use DPAPI's to encrypt and
> decrypt the secret information

> --
> ===========================================================
> This posting is provided "AS IS" with no warranties and confers no rights
> ===========================================================



> > Hi Sam,

> >     Thanks for your response.  I agree with you on point a (and the part
> > leading up to it).  That was the reason for the post.  Except perhaps
> > I have not been clear enough on my utility.  It has nothing
> > to do with the [web page] server side.  And by client I was meaning
> > customer.

> >     So this little utility takes directives to muck about with web pages.
> > For example, I will pay my credit card bill online once a month.
> > So once a month, my .VBS utility fires up, loads up the OCX that
> > does most of the work, and proceeds to issue a set of directives
> > (residing in the .VBS file) to IE that are something like:

> > "Navigate to Credit card home page"
> > "Enter username: myUserName"
> > "Enter password: myPassword"
> > "Click on the Log On button"
> > ...

> >     Perhaps this alters the remainder of the conclusions.
> >     Csaba



> > > First of all, you should NEVER , EVER have a password inside a vbs file
> even
> > > if you're planning to encrypt it
> > > Second, if you want to handle password fields you should have this done
> on
> > > the Server side, not the client side, (your vbs is, and Runs on the
> server)
> > > because no matter What you do, your client can edit the VBS file or
> Debug it
> > > and just dump out the password in plain text, and you don't want that to
> > > happen

> > > So,
> > > a) Never have a password in a script (client or server side)
> > > b) Never have password handling script running on your client
> > > c) make sure you secure your password handling script on your server
> with
> > > the right Acls's

> > > --
> > > ===========================================================
> > > This posting is provided "AS IS" with no warranties and confers no
> rights
> > > ===========================================================



> > > > This is an issue which I'll have to deal with in a week or two,
> > > > so I'm trying to get a head start on it.

> > > > I have a .VBS script which brings up IE
> > > > (set IE = CreateObject("InternetExplorer.Application"), loads a
> > > > page (think credit card payment page), and then fills out the login
> > > > form.  Everything is working, but I am intensely displeased at
> > > > having my password visible within the .vbs file, although I like
> > > > everything else being visible.  So, in particular, it doesn't bother
> > > > me that someone could come along and edit or run the file (I assume
> > > > I'll have some protection scheme for that), but it does bother me that
> > > > they could look inside the file and actually know my password.

> > > >     Here's what I imagine the goal to be (and please feel free to
> > > > comment about the goal itself, taking into account my motivations):
> > > > I want the script to be viewable, but I don't want the password
> > > > to be viewable.
> > > >     So my first idea was, I'll have a key in the place of the
> password.
> > > > Where "myPassword1" appears, when the time comes to stuff the
> > > > password field (I will have ahold of the actual <INPUT type=password
> ...>
> > > > object and will just set its .value attribute), I would do some kind
> > > > of a lookup within some imagined windows cache of passwords
> > > > using "myPassword1" as the key.
> > > >     But I don't like this idea because if it's a "standard windows
> lookup
> > > > scheme", then knowing the key would be tantamount to knowing the
> > > > password (Ie. someone else could write a program stub to get the
> > > password).
> > > > I would have to grow my own encryption / lookup scheme, which
> > > > I could do, but it's something I'd like to avoid (and I'm sure my
> > > > issues have been addressed 1000s of time over).
> > > >      So maybe windows has a standard scheme where it would transfer
> > > > a "looked up password" directly to the <INPUT type=password ...>
> object
> > > > without giving any other prying software a chance to look at it.

> > > >     The end goal of all this is that eventually, the .VBS files will
> > > reside
> > > > on clients' systems (or I might want to publish a script without
> > > > accidentally revealing a password, or demo my software and
> > > > safely show the file to a client), and the script will be run on an
> > > > automated basis.  (For example, a script to clean out the spam
> > > > in my yahoo mailbox involves logging in to yahoo)

> > > >     So on the one hand, having a .vbs file which logs in (regardless
> > > > of password management scheme) to some page exposes that
> > > > account to abuse/exploit.  On the other hand, automated systmes
> > > > require password management.  I am trying to find myself between
> > > > these two poles.  For the nonce, I'd prefer small and practical.
> > > > I'm open to all comments - this is more of a "getting the creative
> > > > juices flowing" kind of post rather than a "backed my way into a
> > > > corner, looking for a way out" post.

> > > >     Regards from New York City, where it's finally sunny after a week
> of
> > > rain,
> > > >     Csaba Gabor

> > > > PS.  encrypting the .VBS file itself is not viable for a solution (it
> can
> > > > be an additional measure).  Even if it was secure, it obscures the
> > > > original .vbs file, which I don't want to be required.



Sun, 20 Nov 2005 06:39:48 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Password Reset Issue

2. storing username & password in session table

3. Two issues regarding xfer of messages from personal stores to and from Exchange

4. Issue? Stored Proc Param w/Crystal 6.0

5. Issue with OCX and SQL Server Stored Procs?

6. Performance Issue with SQL Stored Procedure

7. Stored Procedures Parameter issues

8. multiple queries / stored procs / connection issues

9. ADO cursor issue with stored proc.

10. Performance Issues with Stored Procedures

11. Performance Issue with SQL Stored Procedure

12. Stored Passwords

 

 
Powered by phpBB® Forum Software