Secure auto-login (remember me) - possible?

Hi!

I'm trying to build a "Remember Me" auto-login feature but all solutions I
have seen on the Internet are done insecurely.
The way I see it, cookie is always transmitted in cleartext, so anyone could
steal it and acces the user's account without problems. At least in all
implementations I have seen.

What is more: I think there is no way to store data on client computer and
transmit it on challenge / response mechanism.

Am I right?


I thought I might have a solution to this, but when trying to implement it I
figured out that JS can't access SSL-only cookies. :(
This is the solution I had in mind (it can't be done, but anyway):
The cookie should be set SSL-only (even though we don't have SSL), but
readable by JavaScript.
Once the user comes (again) to the side, it gets a challenge string from
server. JS checks and notices the SSL-only cookie, makes a hash from the
SSL-only cookie and the challenge string, then set a normal cookie with it
and redirects the browser to the same page - which posts the normal cookie
to the server. Server then checks this normal cookie if it is a hash of
challenge+SSL-only cookie, and if so, it is OK. If not - login fails.

Unfortunately JS can't read SSL-only cookies and all non-SSL cookies are
transmitted as cleartext. :(


Any thoughts on how to implement secure "remember me" without SSL would be
appreciated. Even "it can't be done" would be helpful... :)

Best,

Anze

To be more precise: to make "remember me" secure one would need a way to
access cookies via JS, but the cookies should not be transported via HTTP
headers.

Can this be done?

Best,

Anze

Anze schrieb:
> Hi!
>
> I'm trying to build a "Remember Me" auto-login feature but all solutions I
> have seen on the Internet are done insecurely.
> The way I see it, cookie is always transmitted in cleartext, so anyone could
> steal it and acces the user's account without problems. At least in all
> implementations I have seen.

The cleartext is not the problem, you can store encrypted info in the
cookie by encrypting it on server side before sending the cookie.
But if someone steals the cookie it doesn't matter if it is encrypted or
not, the server needs to know if this cookie really belongs to the user
who authenticated or the one who stole it and that is not really
practical. Evene if you add info like ip browser etc to the cookie and
then compare it next time some user sends it, it is no guarantee that
the bad guy doesn't have the same vals, for example both use the same
browser and proxy.


>
> What is more: I think there is no way to store data on client computer and
> transmit it on challenge / response mechanism.

Exactly

>
> Am I right?
>
>
> I thought I might have a solution to this, but when trying to implement it I
> figured out that JS can't access SSL-only cookies. :(

That would be really bad:-)

> This is the solution I had in mind (it can't be done, but anyway):
> The cookie should be set SSL-only (even though we don't have SSL), but
> readable by JavaScript.
> Once the user comes (again) to the side, it gets a challenge string from
> server. JS checks and notices the SSL-only cookie, makes a hash from the
> SSL-only cookie and the challenge string, then set a normal cookie with it
> and redirects the browser to the same page - which posts the normal cookie
> to the server. Server then checks this normal cookie if it is a hash of
> challenge+SSL-only cookie, and if so, it is OK. If not - login fails.
>
> Unfortunately JS can't read SSL-only cookies and all non-SSL cookies are
> transmitted as cleartext. :(
>
>
> Any thoughts on how to implement secure "remember me" without SSL would be
> appreciated. Even "it can't be done" would be helpful... :)
>

It can't be done in a completely secure way. Dependig on what you want
to do you could make this less secure but comfortable enough,.
For example the cookie with auth data is enough to view certain things,
if one does admin tasks, he needs to authenticate first even if he has
the correct auth data in a cookie. So you would have a two level
security. Or just use the cookie to store the username and always
request the password to auth and then set some authflag in your
phpsession data, this way the user has to input only his pass and not
the username, this is more comfortable then typing both vals but still
secure enough.



> Best,
>
> Anze

Ric wrote:

> Anze schrieb:
>> What is more: I think there is no way to store data on client computer
>> and transmit it on challenge / response mechanism.
>
> Exactly

AFAIK any data stored in a format accessible to javascript (i.e. in a
cookie) will be sent over the internet in the request for the page which
contains the javascript. Until you can dissociate these, a challenge
response mechanism will be invalid. Mozilla based browser used to allow you
to have limited local I/O from signed scripts - but its not a very
practical solution.

>
>>
>> Am I right?
>>
>>
>> I thought I might have a solution to this, but when trying to implement
>> it I figured out that JS can't access SSL-only cookies. :(
>
> That would be really bad:-)

Are you sure? I think you are confusing the HTTPOnly attribute with the
secure attribute.

>>
>> Any thoughts on how to implement secure "remember me" without SSL would
>> be appreciated. Even "it can't be done" would be helpful... :)
>>
>
> It can't be done in a completely secure way.

Yes it can (without SSL). There are pure javascript implementations of RSA
(asymmetric encryption) but I suspect you'd need to keep changing the
encrpytion key to prevent replay attacks. Its not worth busting the grey
cells when SSL should just work.

Just use SSL.

C.

Colin McKinnon schrieb:
> Ric wrote:
>
>> Anze schrieb:
>>> What is more: I think there is no way to store data on client computer
>>> and transmit it on challenge / response mechanism.
>> Exactly
>
> AFAIK any data stored in a format accessible to javascript (i.e. in a
> cookie) will be sent over the internet in the request for the page which
> contains the javascript. Until you can dissociate these, a challenge
> response mechanism will be invalid. Mozilla based browser used to allow you
> to have limited local I/O from signed scripts - but its not a very
> practical solution.
>
>>> Am I right?
>>>
>>>
>>> I thought I might have a solution to this, but when trying to implement
>>> it I figured out that JS can't access SSL-only cookies. :(
>> That would be really bad:-)
>
> Are you sure? I think you are confusing the HTTPOnly attribute with the
> secure attribute.

No I guess I ddin't make myself clear, it would be really bad if js
couldn't access these cookies on the clients computer because then a
cookie would be useless.

>
>>> Any thoughts on how to implement secure "remember me" without SSL would
>>> be appreciated. Even "it can't be done" would be helpful... :)
>>>
>> It can't be done in a completely secure way.
>
> Yes it can (without SSL). There are pure javascript implementations of RSA
> (asymmetric encryption) but I suspect you'd need to keep changing the
> encrpytion key to prevent replay attacks. Its not worth busting the grey
> cells when SSL should just work.
>

Ok I can follow your thoughts, but you probably forgot, that he wanted
to store a persistent cookie, so when the user comes back the next day
he doesn't have to login. If you consider that then a cookie can also be
stolen if someone has access to his computer, for example through a
local account, or through some trojan etc. One of the classics is,
lloking at edonkey, kazza etc. for cookies, some users are dumb enough
to also share their home drive:-)

In this case it doesn't help to encrypt the cookies content, because if
he has the cookie then there is no need for him to decrypt it:-)


> Just use SSL.
>
> C.

Hi!

First of all, thank you both for answering and my sincere apologies for not
replying.
I have completely forgotten that I have posted a question here... :(

>>>> I thought I might have a solution to this, but when trying to implement
>>>> it I figured out that JS can't access SSL-only cookies. :(
>>> That would be really bad:-)
>>
>> Are you sure? I think you are confusing the HTTPOnly attribute with the
>> secure attribute.
>
> No I guess I ddin't make myself clear, it would be really bad if js
> couldn't access these cookies on the clients computer because then a
> cookie would be useless.

I have checked and if either httpOnly or secure is set then JS cannot access
the cookie. Which basically means you can't implement a challenge-response
mechanism for "remember me" authentication, because the cookie is sent
unencrypted anytime the user comes to the login page.

As some measure of security (by no means adequate, of course) you could
change the cookie value anytime user comes to the page. If someone uses the
old value then this is cause for alarm - either a hacker is trying to use
an outdated cookie or the hacker _has_ used the outdated cookie and now
hold the current one.

But that only notifies of a hacking attempt / breakin (and only in most
cases, not always).

>>>> Any thoughts on how to implement secure "remember me" without SSL would
>>>> be appreciated. Even "it can't be done" would be helpful... :)
>>>>
>>> It can't be done in a completely secure way.
>>
>> Yes it can (without SSL). There are pure javascript implementations of
>> RSA (asymmetric encryption) but I suspect you'd need to keep changing the
>> encrpytion key to prevent replay attacks. Its not worth busting the grey
>> cells when SSL should just work.
>>
>
> Ok I can follow your thoughts, but you probably forgot, that he wanted
> to store a persistent cookie, so when the user comes back the next day
> he doesn't have to login. If you consider that then a cookie can also be
> stolen if someone has access to his computer, for example through a
> local account, or through some trojan etc. One of the classics is,
> lloking at edonkey, kazza etc. for cookies, some users are dumb enough
> to also share their home drive:-)
>
> In this case it doesn't help to encrypt the cookies content, because if
> he has the cookie then there is no need for him to decrypt it:-)

Like they say, programming is a race between programmers, trying to build
better, idiot-proof programs, and the Universe, trying to build better
idiots. So far the Universe is winning. :)

If someone gives away his cookies then this is indeed a problem, but not
mine anymore. ;)

Again, thank you both for your thoughts.
I will just notify the clients of the potential security implications and
let them decide whether they want this feature or not.

Best,

Anze