By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,795 Members | 1,251 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,795 IT Pros & Developers. It's quick & easy.

REmembering User accounts without using cookies.

P: n/a
Hey!

We need a solution for a problem. We're designing a site where users hate...
absolutly hate... with a passion to sign in with a user name / password
system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't
like using cookies either. Is there another method we could use? Encrypted
XML on the client's machine was brought up, but that still has security
issues.

Is there other options for this scenario?
/RT
The Monkey at the Keyboard
Nov 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
Hey!

We need a solution for a problem. We're designing a site where users hate... absolutly hate... with a passion to sign in with a user name / password
system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't
like using cookies either. Is there another method we could use? Encrypted
XML on the client's machine was brought up, but that still has security
issues.


What's wrong with cookies?
--
John Saunders
johnwsaundersiii at hotmail
Nov 18 '05 #2

P: n/a
If you don't want cookies, you are pretty much out of options. IE Security
wouldn't let you write any files on the client's machines

I'm not sure what you have against cookies, that is a pretty standard way of
accomplishing this. You can encrypt the password before storing it in the
cookie.

"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
Hey!

We need a solution for a problem. We're designing a site where users hate... absolutly hate... with a passion to sign in with a user name / password
system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't
like using cookies either. Is there another method we could use? Encrypted
XML on the client's machine was brought up, but that still has security
issues.

Is there other options for this scenario?
/RT
The Monkey at the Keyboard

Nov 18 '05 #3

P: n/a
It's not that cookies won't cut it, it's that the lead Designer doesn't want
to use them... plus the people that will be using this system have a system
tighter than... to put it in plain terms... if they wanted to download an
image to their computer, they'd have to go through about 5 different levels
of management to get an OK for it.
"Marina" <so*****@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP09.phx.gbl...
If you don't want cookies, you are pretty much out of options. IE Security wouldn't let you write any files on the client's machines

I'm not sure what you have against cookies, that is a pretty standard way of accomplishing this. You can encrypt the password before storing it in the
cookie.

"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
Hey!

We need a solution for a problem. We're designing a site where users

hate...
absolutly hate... with a passion to sign in with a user name / password
system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't
like using cookies either. Is there another method we could use? Encrypted XML on the client's machine was brought up, but that still has security
issues.

Is there other options for this scenario?
/RT
The Monkey at the Keyboard


Nov 18 '05 #4

P: n/a
If they use IE, I would think they'd be ok with cookies. They can explicitly
control from which sites to accept cookies, and I believe that list can be
locked by using Group Policy, so that individuals can't change it.

--
John Saunders
johnwsaundersiii at hotmail
"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
It's not that cookies won't cut it, it's that the lead Designer doesn't want to use them... plus the people that will be using this system have a system tighter than... to put it in plain terms... if they wanted to download an
image to their computer, they'd have to go through about 5 different levels of management to get an OK for it.
"Marina" <so*****@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP09.phx.gbl...
If you don't want cookies, you are pretty much out of options. IE Security
wouldn't let you write any files on the client's machines

I'm not sure what you have against cookies, that is a pretty standard way of
accomplishing this. You can encrypt the password before storing it in the cookie.

"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
Hey!

We need a solution for a problem. We're designing a site where users

hate...
absolutly hate... with a passion to sign in with a user name / password system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't like using cookies either. Is there another method we could use?

Encrypted XML on the client's machine was brought up, but that still has security issues.

Is there other options for this scenario?
/RT
The Monkey at the Keyboard



Nov 18 '05 #5

P: n/a
Well, they can't have their cake and eat it too.
Meaning, that if they are unwilling to do something as harmless as to allow
cookies to come from your site - they can't then expect to have the username
and password remembered.

In fact, any other solution - like storing encrypted XML files, etc, would
actually be less secure. Imagine if a web site can write any file it wants
to, to your computer - what a huge security hole!

And again, there is nothing stopping you from encrypting whatever it is you
want to store in the cookie, to make sure that it is safe.

"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
It's not that cookies won't cut it, it's that the lead Designer doesn't want to use them... plus the people that will be using this system have a system tighter than... to put it in plain terms... if they wanted to download an
image to their computer, they'd have to go through about 5 different levels of management to get an OK for it.
"Marina" <so*****@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP09.phx.gbl...
If you don't want cookies, you are pretty much out of options. IE Security
wouldn't let you write any files on the client's machines

I'm not sure what you have against cookies, that is a pretty standard way of
accomplishing this. You can encrypt the password before storing it in the cookie.

"Ryan Ternier" <rt******@icompasstech.com.spamproof> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl...
Hey!

We need a solution for a problem. We're designing a site where users

hate...
absolutly hate... with a passion to sign in with a user name / password system. They want to sign in once, and that's it.

User's are all behind an internal IP so we can't use the old method of
remembering IP's as that would mess up user preferences. We really don't like using cookies either. Is there another method we could use?

Encrypted XML on the client's machine was brought up, but that still has security issues.

Is there other options for this scenario?
/RT
The Monkey at the Keyboard



Nov 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.