Re: WAYS OF AUTHENICATION - open discussion

On 11/5/00 4:13 AM this was written: > So in other words, if I have the file in /myuser instead of > /myuser/public_html, the data is secured? Unless of course I have some > weird server configurations. It's secured insofar as someone from outside the site can't include the file via a url. But if htey have access to telnet to the server or got your FTP password then it can be compromised, it's almost impossible (that I know of) to be completely and utterly secure when it comes to those factors. > until now I just didn`t let the user to be idle more than 30 minutes, but > the idea of not letting the user be in over 2h at all, sounds good as > well, as the noone will probably need more time anyway (at least in my > particular case. I don`t have a cron job, but well, if the 'refreshed' has > expired or 2h has gone past, I guess there`s no problems (at least not big > ones). And in my case, if there are undeleted old sessions, then I have > this little addition that when someone logs in, the useless sessions will > be deleted at the same time. (not only the logging user ones, but rather > all). I agree, without a cron job you can have the old sessions cleared out when the front page is hit or when the next user logs on. > Right now I have passwords encrypted with md5 in php and then put to a > database. ah, jess, lets talk about different encryption methods as > well,which are the best ones? As said, I`m usaully using md5(and already > in php), but would it be any use to add the already encrypted password to > database with PASSWORD()? E.G > $myuser = md5('mypass'); > mysql_query("INSERT INTO users(password) VALUES > (PASSWORD('$myuser'))"); > And then when somone logs in, I just encrypt his entered password > and see if the one he entered and the one in the database match. That one > I havent done yet, but Im definately thinking about it. I´m > not going to > keep national secrets on the site, but...well, the securer the better. Hmmm, I never thought about this. First, considering md5. I don't know much about it, suppose I should read, jess sec.... Hmm, how do you decode md5? And when you encode a string, is it always the same string so you just encode it to check against the db? If it's always the same string when encoded, is is possible to break the code? I'm clueless in that respect. I was going to warn against using PASSWORD() in the db because you can't unencrypt that but you weren't going to need to unencrypt it. Assuming md5 is as good as it seems, sure, that sounds like a good plan. > Can we truly call it a drawback? The security matters, user satisfaction > too of course, but as he (or she ... without wanting to insult out female > companions) will have the opportunity to change it again, then in my > opinion there are no problems. True, in actuality it's not too much of a drawback, just a time-delay to have to change the password twice. > I hope more people will have something to say concerning security of web > sites. I don't know, best security is put it behind an ssl layer. My methodology I described before is used in a control panel that's behind a secure server. -- Thomas Deliduka IT Manager ------------------------- New Eve Media The Solution To Your Internet Angst http://www.neweve.com/