5 ms·
I hear, "Don't roll your own session store" frequently, but I wonder, is there any way to not roll your own session store when you are creating a single-sign-on
by euroclydon 16y ago
I hear, "Don't roll your own session store" frequently, but I wonder, is there any way to not roll your own session store when you are creating a single-sign-on application across multiple server technologies (PHP, ASP.NET, Rails)?
- tptacek 16y agoNope. Be really, really careful. This is one of the top game-over problems that happens to smart dev teams.
- ichverstehe 16y agoCan you elaborate on that?
- euroclydon 16y agoGo back and read through Thomas's comments here regarding attacks on encrypted passwords. Try this: http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.ycombinator.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.yc... Find all his warnings, and don't make any of the mistakes he mentions, and I'll bet you will be fine.
- tptacek 16y agoI'd be more worried that: * The session token you come up with will be insecure, like PHP's have been as recently as (I think?) this year * That you'll end up reinventing session fixation vulnerabilities * That you'll screw up session timeouts and logouts and succumb to "permanent" session hijacking flaws * That you'll try to encode encrypted information into the session cookie itself, rather than just an opaque random token, and open that whole kettle of worms.