Forgot to copy the list... Sent from my iPhone
Begin forwarded message: From: "Simon J Oliver (sjoliver)" <sjoli...@memphis.edu<mailto:sjoli...@memphis.edu>> Date: February 20, 2013, 8:23:33 PM CST To: Ken Anderson <kenli...@anderhome.com<mailto:kenli...@anderhome.com>> Subject: Re: Storing a user in a cookie Yes I think OAuth could potentially work, although you'd probably want some sort of local session management /caching anyway to avoid the need to validate every request with the identity provider. OAuth has the advantage at least over Pascal's original scheme that it provides an form of expiry/invalidation mechanism that allows a token to be repudiated if needed. Depending on how long you want the tokens to live and/or how sensitive the data is, you'd probably want to ensure that your app was served solely over SSH to minimize the risk of token theft. It really all depends on you, your users and your data... I can't imagine many circumstances where just re-locking the door to fix a confidentiality/integrity breach after the fact is a 'good enough' solution to keeping an app secure (especially where the breach can have happened through no identifiable fault of the user, as in the case of tokens sniffed off the network) but if that works for your scenario, then that's great. :-) Simon Sent from my iPhone On Feb 20, 2013, at 11:36 AM, "Ken Anderson" <kenli...@anderhome.com<mailto:kenli...@anderhome.com>> wrote: 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) <sjoli...@memphis.edu<mailto:sjoli...@memphis.edu>> 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" <jtay...@oeinc.com<mailto:jtay...@oeinc.com>> 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 <prob...@macti.ca<mailto:prob...@macti.ca>> 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 (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com This email sent to jtay...@oeinc.com<mailto:jtay...@oeinc.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/sjoliver%40memphis.edu This email sent to sjoli...@memphis.edu<mailto:sjoli...@memphis.edu> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com This email sent to kenli...@anderhome.com<mailto:kenli...@anderhome.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
