Re: Storing a user in a cookie
Re: Storing a user in a cookie
- Subject: Re: Storing a user in a cookie
- From: Ken Anderson <email@hidden>
- Date: Wed, 20 Feb 2013 10:35:03 -0700
Doesn't OAUTH do exactly what you're asking for? For users that use one of my iOS apps (RailTime), we get an OAUTH secret from Twitter that's unique to us. The user can always log onto Twitter and disable our OAUTH secret, but otherwise it lasts forever.
If a user complains that they're seeing strange behavior on their account, revoke the secret and issue another one.
Ken
On Feb 20, 2013, at 10:24 AM, Simon J Oliver (sjoliver) <email@hidden> wrote:
> I think that first you have to think seriously if you really want to do this. There are two problems to guard against - making up tokens, and re-using other people's. Encryption might fix the first, but not the second.
>
> If you do REALLY want to do it, you have to basically emulate a session ID, and store that in the database or in a file or something, and then look it up - with some sort of expiry period built in. You can generate the tokens with a hash function, it doesn't need to be reversible encryption.
>
> If there is no expiry mechanism then anyone who has access to your token (e.g., from sniffing network traffic) from the cookie can masquerade as that user at any time (years later even), bypassing authentication, and you have no way to stop them short of invalidating the user id.
>
> Session id's are always a bit of a trade off security wise, but you need some way to check that the return of the user is plausible and not just accept any connection that knows the magic words.
>
> Simon
> CISSP-ISSAP, ISSMP, GWAPT, OSWP
>
> Sent from my iPhone
>
> On Feb 20, 2013, at 11:08 AM, "Jesse Tayler" <email@hidden> wrote:
>
>> you're only going to compare one resulted cypher to another resulted cypher you have stored -- knowing they calculate to the same result and are the same/correct is enough to ensure people haven't just made up a cookie and you'd never reveal a cookie that would be useful.
>>
>>
>> On Feb 20, 2013, at 12:02 PM, Pascal Robert <email@hidden> wrote:
>>
>>> What would you use for storing details about an user in a cookie for stateless apps (e.g., in a "keep me logged" situation)? I see two solutions:
>>>
>>> - Using BlowFish to encrypt the username in the cookie, and to decrypt the value of the cookie to see who is the user;
>>>
>>> - Encrypting the username with BCrypt, storing the encrypted username in the database and in the cookie, and doing a comparison.
>>>
>>> Opinions? The only problem I see with the first one is that if someone find the cipher key, you're toast, but at the same time, if they find it, it's probably because it was stored in the file system or in a SCM, so if they found it, you will probably have other problems too.
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden