php - Authenticate system without sessions - Only cookies - Is this reasonably secure? -

php - Authenticate system without sessions - Only cookies - Is this reasonably secure? -

i'm interested in advice/opinion on security problem.

i thinking on doing this:

get hash mac (sha256) string built userid + expirationtime , secret key string built secret string , $_server['http_user_agent']. get hash mac (sha256) userid + expirationtime , secret key made hash (from step 1). build string userid|expiration| , made hash (from step 2). encrypt given string (from step 3) 'rijndael-256' algo. (mcrypt family of functions). encode base64. set cookie given value.

what think. ok? else implement $_server['http_user_agent'] check, create sure cookie isn't stolen (except ip address)?

p.s. sensitive info cookie contain userid.

edit: ok clear things. i'm trying create "safe" auth scheme doesn't rely on sessions. app in question build more or less pure restful api.

step 2:

problem: "fu’s protocol not provide reply question. there 1 key involved in fu’s proto- col, namely server key. 1 straightforward solu- tion utilize server key encrypt info field of every cookie; however, solution not secure."

solution: "our solution problem simple , efficient. propose utilize hmac(user name|expiration time, sk) encryption key. solution has fol- lowing 3 properties. first, encryption key unique each different cookie because of user name , expiration time. note whenever new cookie created, new expiration time included in cookie. second, encryption key unforgeable because server key kept secret. third, encryp- tion key of each cookie not require storage on server side or within cookie, rather, com- puted server dynamically. " paper "a secure cookie protocol" alex x. liu1 , jason m. kovacs

step 4: encrypts info (which this: 'marko@example.com|34234324234|324erfkh42fx34gc4fgcc423g4'), client couldn't know what's inside.

step 5: base64 encode there create final value pretty.

i'll bite.

in order maintain semblance of state need identify user using key of type. key sent browser cookie or through query string parameters.

now, validation of key can occur within web server (session) or through checking other storage mechanism, database record.

the key should obfuscated using mechanism. reason obfuscation create harder guess values other keys might have if originating user or else decides inspect value. example, if key user id (not recommended) , using incrementing ints it's trivial guess other user keys. i want stress obfuscating ( or downright encrypting ) key provides absolutely no protection against hijacked session. create harder guess other peoples session keys.

that said, believe key should have nil @ user id , instead other near random value generated guid. quite frankly base of operations 64 encoded guid @ exact same level of security encrypting user id + time. it's 1 more computationally intensive on server other.

of course, key alter upon each request. browser posts something, generate new key , send back. in event browser posts out of date key log , kick them login screen. should prevent replay attacks .. degree. however, introduces other challenges such using button on various browsers. so, may not want go downwards path.

that said can't depend on client ip address because same user might send follow requests using different ip. can't depend on browser fingerprinting because decent hacking tool capture , submit same values regardless of whatever using.

now, if want right should have ssl turned on. otherwise you're wasting time. entire conversation (from login screen on) needs encrypted. if it's not hear cookie, replay , hijack session. point don't need know values contained therein utilize them. of hashing, etc have fluff increment server load.

did utilize ssl? ;) encrypt traffic origin of conversation , attacker cannot replay same packets have negotiate own handshake server. means have ensure whatever session id utilize non-guessable 1 logged in user can't take on another's session.

so, sum up: method posted waste of time.

you much improve off getting $10 ssl certificate , using base of operations 64 encoded guid session id. how store session info on server doesn't matter... except in load balanced situations. @ point needs out-of-process , backed database server.. that's question.

php security authentication cookies