   [web] Secure login strategy
  Does this sound like a viable secure login strategy:Upon logging via HTTPS webpage a UniqueID is assigned to the user, the UID is stored on the server (DB probaly) and in a client cookie, then do a check on each user request by matching User name and stored UID, a miss-match causing a return to the login page. And have some sort of timeout of course.Any thoughts would be appreciated.   
  I would avoid the cookie, as that is something thats stored on their computer. Obviously hash the password on login. I suggest when assigning the unique id, add it to the session, and just keep it fairly unique. Something alpha-numeric with the odd capital letter or two.   ;  I fail to see how the above suggestion helps at all.Session data is nothing more than a file stored on the server with a specific key.  That same key is transferred to the client as a cookie.  Whenever the client accesses a page, the key is then transferred back to the server so the server knows which session file to use for this request.agm's suggestion is essentially storing the unique ID in the session file.  This is no different than just not using a unique ID at all.I'm also having trouble understanding why Guthur wants to assign a unique ID to the user in a cookie?  Isn't that already the job of the session key anyway?  All you've done is taken one unique ID and made two.  Granted, that makes it more difficult to just flat out guess session keys, but it is quite improbable for an attacker to just guess at currently active session keys already, anyway.  They usually acquire it through cross-site scripting attacks, in which case they'd acquire any cookie data stored on the clients computer anyway - including that unique ID.Really, the only way to add additional authentication to session keys is by also storing the IP address that is associated with the particular session on the server.  This isn't really necessary for low-security sites, though.Why not just let the session do it's job and leave it at that?   ;Quote:Original post by CaspianBI'm also having trouble understanding why Guthur wants to assign a unique ID to the user in a cookie?  Isn't that already the job of the session key anyway?YesQuote:Original post by CaspianBReally, the only way to add additional authentication to session keys is by also storing the IP address that is associated with the particular session on the server...And also by taking the user's browser identification. IP addresses can be problematic in some cases due to weirdlings like AOL that (or at least used to) use this funky round-robin IP assignment.That said, this whole thread is weird.I think what the OP was getting at is this:Store the user's session key in a database/file and put all your fun info on the server instead of in cookies (which are client side and can be manipulated). Using this strategy, the only thing that exists in the client cookie is the session ID itself. However, as noted, that is assigned by your session handler.   ;  Thanks, So the difficulty is trying to identify the client in a Unique manner that is hard to spoof, which is not easily done?I'm just trying to get a handle on the best approach, I'm assumming now that a session ID is the least hassle free, if a little susceptible to attack.Would assigning a new ID every request help much, where by the the previous ID is used to ensure that the requestor is valid then assign a new one. If a missmatch occurs in the chain then kill the session. This could possible be done asychronisely to users request as well so as to catch the missmatch as early as possible. Or is that just overkill and/or impractical, I know for one thing request traffic would be increase considerably.I would be interested in any alternatives, for implementation within a website.I'm just hoping to sound of some ideas, I'm a little new to this field.   ;  Generally speaking, most web/scripting languages handle all of that for you. For instance, PHP has a collection of session handling functions, something like session_start() and session_destroy(). You don't need to worry about the details unless you are running a serious business and money is at stake.If that's the case however, it's not too hard to record the user's IP address and Browser identification string as extra authentication.Your security concerns would be better spent worrying about hack attempts, SQL injection, query string manipulation, etc.   ;  Security is *hard*. Be smart, do yourself a favour and use a standard, well tested authentication system. There are plenty of those around for PHP. You can be even smarter and use something like OpenID for which there are also plenty of PHP libraries available. OpenID can be a bit hard to implement but it saves you from having to deal with storing passwords and the like. As a visitor to your site, the bottom line is that I trust my OpenID provider more than I trust you to get a tough subject like security right.Jeff Atwood had some nice things to say about that.   ;  Fair points.Some caveats though from my situation and current outlook:I don't use PHP I prefer ASP.NET, it also has some standard authetication stuff though.I was recently at a job interview and they asked about overcoming this particular problem of secure login, at the time I hadn't even looked at it.Just because its hard is no reason to ignore it, life's hard but I keep plugging away ;) hhh and software development is fun and what I do, why should I ignore some of it.My thought on a standard implementation is that it is widely known and so easier to break, the attacker has had a long time to analysis something that has been in the wild, as oppose to a custom implementation which will be an unknown, for a while at least :).I suppose I am really try to get a handle on where the likely avenues of attack are. Thanks Ieiavoia for those reminders :).Jeff Atwood's comments seemed to be centred on password security, and off the top of my head:-Encourage strong User passwords.-HTTPS communication during login.-Limited Attempts before attack warning and account freeze.-Education of when and where you will ask for a password.I'm thankful for the input guys, I would like to explore this subject as much as possible, so if anyone has anything else feel free to chip in :)   ;  You should also read some of the links that Jeff posted in his story, especially "You're Probably Storing Passwords Incorrectly" and the links leading away from there about hashes and rainbow tables.Quote:Just because its hard is no reason to ignore itTrue. But if you get some hard piece of code wrong, you just have a buggy piece of code. If you get security wrong then you have potentially exposed all your users private data and credentials. And you *will* get it wrong. If you have a login on your website  then you become responsible for safeguarding your user data. It means you have to do everything possible to make sure that private data and credentials remain private. If that means using a standard library instead of solving a hard problem that you find interesting then you should do so.Quote:My thought on a standard implementation is that it is widely known and so easier to breakThat's usually not true, see Linus' Law. "Given enough eyeballs all bugs are shallow". All programs have bugs. Guaranteed. The only way to find and eliminate these bugs is giving it as much review as possible from as many people as possible. They can find bugs you can't see. Writing custom authentication code and keeping it secret is just security through obscurity.   ;  Thanks for the pointers Sander.This is all mostly for learning and kudos at an interview. Of course if it was a commercial endeavour I would use something tried and tested, most likely; I don't have the means for exhaustive testing.But I wanted to concentrate on something low level like this because the higher the level and with the more off shelve code used, the more complete the product has to be which means I have to wear far to many hats eg, developer, system architect, graphic design, QA etc. I am hoping to make a multiroom chat service with a custom login. I have the prototype for the chat system just looking at the login now. This gives me a need for a database as well for more kudos :)   