Pedro Pontes wrote: > with a SIMPLE "equals" test. So if a user happens to get that crypted value > of the password (from a temporary file on the server, for example), then all > the little devil has to do is to create a dummy session user object, or in > your case, array, set its password value to the stolen crypted hash and then > link freely to any of your pages.
well.... simply put? no.. If a user can get the crypted value off your server, AND also figure how to trick the PHP engine into accepting a session cookie that wasn't created on your domain, then that would be either: a) you have dangerous and volatile PHP scripts that allow users to perform such nasty tricks b) your server security should be greatly improved.. Jon Haworth wrote: > Why are you passing the password around, hashed or not, in the first place? > Just have a yes/no flag for whether the session is an authenticated user or > not. > Is there any particular reason why you'd need to reauthenticate on every > page? yes.. too true.. and simply put.. I could just pass the key or something around instead and then in my PHP header that runs on each and every page just reload a array with all the details anyway.. instead of passing around the array.. oh and as for "reauthenticating" well that's done because.. well stupid really when you think of it.. Unless they breach PHP as mentioned above, and trick the session system, then there is little need to keep auth'ing them.. Haha.. Actually I just looked at my code.. Sorry I was mistaken.. due to the complexity of my site. it doesn't actually "reauth" as such.. instead it checks to see the "status" of the user and does some log updates.. (to keep track of user's still online etc..) ... when I say status.. I mean if I ban/block users while logged in.. the changes happen AS SOON as they view another page on the site and they get a lovely page telling them of their predicament :) Anywayz.. very interesting topic.. I will keep an eye on this.. Miguel says: > This would only work if some other user is able to create files that the > web server thinks are part of your domain (since the session cookies are > domain-specific). Sounds to me like your problem here is severe server > misconfiguration. If your server environment is that insecure, then > worrying about anything else is sort of a waste of time. Yes.. Too true.. Michael Kismal says: > What I can't figure out is why you're allowing people to just randomly > put pages on your server. If someone was to randomly register a similar > user object, etc - why bother? If I can put pages on your server and > execute them, I'd do some something far more malicious than just pretend > I'm "user X". Precisely what I am getting at too.. Yes the general opinion seems to be: "If someone can get the session handler of the PHP engine tricked so easily, or gain access so easily to your site... Then you'd better look into that WAY before you start picking on authentication schemes".. No harm intended ok.. Just pointing out some facts.. Hope I can help.. Would love to demonstate some ideas/etc.. about how I do security stuff.. Bye ::::::::::::::::::::::::::::::::::::::::::: : Julien Bonastre [The-Spectrum.org CEO] : A.K.A. The_RadiX : [EMAIL PROTECTED] : ABN: 64 235 749 494 : QUT Student :: 04475739 ::::::::::::::::::::::::::::::::::::::::::: ----- Original Message ----- From: "Pedro Pontes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, May 04, 2002 12:33 AM Subject: Re: [PHP] Secure user authentication > First of all, thank you for your devote answer. > > The method I was thinking about before was to pass the md5 hash of the > password around, as the passwords are already md5'ed in the DB. Your method > seems more secure as you use a totally spiced-up and personalized encryption > engine. > > But, the main question remains, I think. If you pass your crypted password > around, then, in each page, you must check it agains't the database entry > with a SIMPLE "equals" test. So if a user happens to get that crypted value > of the password (from a temporary file on the server, for example), then all > the little devil has to do is to create a dummy session user object, or in > your case, array, set its password value to the stolen crypted hash and then > link freely to any of your pages. > > Am I right? Thanks again. > > -- > > > Pedro Alberto Pontes > > "The_radix" <[EMAIL PROTECTED]> wrote in message > 003601c1f2aa$6120dbb0$f86086cb@oracle">news:003601c1f2aa$6120dbb0$f86086cb@oracle... > > Hmm yes good question.. > > > > Security was (still is) a major for my organisation's site and I did > > something a little unique and robust.. > > > > > > I love programming and I hate "stealing" (some call it borrowing) other > > programmer's scripts/code from the web.. therefore I write it _all_ > myself.. > > > > > > Trust me.. Sometimes this is a dumb attitude to take such as when I > created > > my first Perl discussion forum.. still running I think > > (http://the-radix.hypermart.net i think) and that consisted of this huge > > perl system to maintain the files etc.. for members and the forum.. > > > > > > Anyway! off the sub now.. > > > > > > I used sessions and pass around the array of columns for that member/user > .. > > but the password is put through my own fairly unbreakable (yes.. I am > > serious) password key system.. > > > > > > An idea to make your own safe keys to pass them around or use for > > authenticating is simple maths and a crypt() or my preferred: md5() > > function.. > > > > > > I simply do some lovely maths like for each char of pword I loop through > > them and append them onto the entire pword string plus the length, get the > > md5 of that.. then md5 that md5 with the md5 of the previous result and > then > > do some maths, pick some specified characters (like every 3rd or whatever > > you wish) .. strrev( reverse the string) md5 that again, all md5'ed > again.. > > > > > > :) haha, you get the idea.. > > > > > > SO basically you'll end up with a nice 32 char string which is QUITE safe > to > > pass around and the chance anyone's gonna decrypt it IMHO is about zilch, > > buckley's, zut, nil, null, zero.. > > > > > > And all you have to do, is when they login once, just run the password > they > > entered through this "algorithm" and check it against the stored algo'd > > password.. > > > > Ah yes that's the next thing.. the DB passwords will also have to be proc. > > using your algorithm.. > > > > So it's kinda like a key security idea.. you are not meant to decrypt md5 > > hashes.. instead recreate it using what you are supplied and then compare > > both hashes.. > > > > > > Simple :P > > > > > > > > > > Ok hope that helps > > > > ::::::::::::::::::::::::::::::::::::::::::: > > : Julien Bonastre [The-Spectrum.org CEO] > > : A.K.A. The_RadiX > > : [EMAIL PROTECTED] > > : ABN: 64 235 749 494 > > : QUT Student :: 04475739 > > ::::::::::::::::::::::::::::::::::::::::::: > > ----- Original Message ----- > > From: "Pedro Pontes" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, May 03, 2002 10:19 PM > > Subject: [PHP] Secure user authentication > > > > > > > Hello, > > > > > > I'm using the regular user authentication method, that is, check the > > > specified login/pass agains't the entries in the DB, if it is valid, > > create > > > the user object and register it with the section. > > > > > > How can we prevent any user from creating a simple PHP page that creates > a > > > simmilar user object, registers it with the session and then links to my > > > pages? One way would be to check, in each page, for the password in the > > > session user object and match it with the DB entry, but storing the > > password > > > in the session is not advisable, as other users in the host system may > > have > > > access to that information. > > > > > > Please advise. > > > > > > Thank you ver much for your time. > > > > > > -- > > > > > > > > > Pedro Alberto Pontes > > > > > > > > > > > > -- > > > PHP General Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
