Page 5 of 5
Re: PHP & MySQL site login, security concepts
Posted: Sat Nov 14, 2009 1:26 pm
by timWebUK
It's similar to the 'Upload from URL' that phpBB has, except rather than storing the file on the server, I'll just store the location in a database and then echo that in an <img> tag. Which would be wide open to XSS, etc.
I was hoping someone would know a good validation method or a better way of getting avatars from other URLs.
Re: PHP & MySQL site login, security concepts
Posted: Sat Nov 14, 2009 1:39 pm
by kaisellgren
I would definitely go for downloading the picture from the site, and storing it on the filesystem for display. It would be less prone to XSS attacks, easier to implement site-wide HTTPS and let you define the HTTP response headers for the client. You would simply attempt to download the picture, save it to the filesystem, and then display it from there.
Re: PHP & MySQL site login, security concepts
Posted: Tue Nov 17, 2009 7:19 am
by timWebUK
Yeah I guess that is the safest way of going about it. Thanks for your help! Everything seems to be going pretty smoothly so far thanks to this forum.
Re: PHP & MySQL site login, security concepts
Posted: Tue Nov 17, 2009 4:40 pm
by batfastad
Hi Kai
I've got the login and auth stuff all sorted now, including session ID/IP throttling.
Now I've just got to write the rest of the code for the site! Thankyou so much for all your help so far. I really should do a write up on all of this at some point. Hopefully others will find my stupid questions throughout this thread helpful!
I've decided to go with e-mail address as the user credential after much discussion in the office. They wanted to keep it easier for people to remember... I did emphasise the security aspect... but that's what we decided.
My next task is a password reset.
My plan is this... user visits a form and enters their e-mail address.
A random hex auth token is generated and stored along with their user DB record... this is e-mailed as a link.
User visits the link and if the e-mail and auth token match, then they get to type a new password (twice for confirmation).
Is that good enough?
I could add a security question when they subscribe... ask them for something from their original subscription invoice (sent via postal mail) or someting.
But I was wondering whether it's worth generating 2 random hex auth tokens for the e-mail link rather than one?
I think i know your answer to this already... if the 1st rand token is strong enough then the 2nd one is useless... right?)

How about a time limit on the auth token?
Cheers, B
Re: PHP & MySQL site login, security concepts
Posted: Wed Nov 18, 2009 1:03 am
by kaisellgren
The approach is okay. Make sure the random token is strong because intruders will always look for the weakest nodes in your chain. A super secure login system with insecure password reset makes no sense. Anyway, how strong exactly should this token be? Well, imagine if our session identifier, which gives an access to the account, has x-bytes of strength, then the password token, which also gives an access to the account, shouldn't be weaker. Otherwise, things don't really make much sense.
In addition to the strength of the token, the token must die after it has been accessed. I also see no reason to allow arbitrary IPs to reset passwords. The password reset could be tied to the account's IP loosely so that people from another countries can't just reset it even if they had the token. A security question can be added, but must not be relied on alone. The token is essential here and should also expire as soon as possible. If you want to take things even further, you can encrypt the email message with GPG.
Re: PHP & MySQL site login, security concepts
Posted: Thu Nov 19, 2009 7:36 am
by batfastad
Hi Kai
Yep completely agree.
I've set this up now with a 10 minute time limit on the auth token and the ip address has to be within a similar range (+/- 255) of the one that requested the auth token.
Going back to the session ID throttling. Here's what I've got going on:
- If the user tries more than 1 session ID in 60 seconds, it registers as a forgery attempt and sets a forgery_timer timestamp
- Once the user hits 15 "forgery attempts" within 10 minutes, the IP will be blocked for 10 minutes
Obviously my criteria for a forgery attempt is quite strict, and a login/logout/login within 1 minute will technically count as a forgery attempt. But it will have to be a rare occasion that someone does 15 of those within 10 minutes. I can tune the timings as necessary though.
Do you think that is a good start point or should I make my timings more aggressive?
Cheers, B
Re: PHP & MySQL site login, security concepts
Posted: Thu Nov 19, 2009 9:39 am
by kaisellgren
I think you should not create/increase the counter for a correct session identifier because it tells you the attempt was legitimate (if not, then it wasn't the throttler's fault).
Re: PHP & MySQL site login, security concepts
Posted: Mon Nov 23, 2009 8:39 pm
by ramblin54321
To Batfastad,
if you were to write a tutorial on how to program a login authorization in php and post a link to it, I would be very interested in seeing it! I know a lot of programming gurus would say to do the research on your own and rtfm; :banghead:but as you have said in your posts: you did a lot of reading and still had many questions. It would save others from too much grief and agony to not have to go through it the hard way. Someone that wants to learn Russian would not read the entire Russian-English dictionary but would just want to get some conversational phrases to start out and would practice with someone that knows it. Please write up a tutorial and make it in very basic terms with explanations, such as whether to use cookies or a session variable. You could start with basic security such as keeping out non-human bots and spam for a site that allows anyone to create a login as in a forum and continue to full security for a user's account that accesses personal files. It would be very much appreciated.
By the way, I read through the posts in this thread and for the most part don't know what you're talking about except for the sha hash which I've read up on.
Re: PHP & MySQL site login, security concepts
Posted: Tue Dec 08, 2009 6:58 am
by timWebUK
Hi,
I've finally implemented my entire registration form and so far it is pretty secure. I had just had a couple of cleaning-up questions.
What's the best way to handle the errors if someone was to bypass the Javascript validations I have in place?
Currently, I handle all the errors on the server-side, set a couple of $_SESSION variables to true, and then when the form gets redirected through a header (in the event of an input error), I display a message based on whether the $_SESSION variable has been set to true or not. It seems to work, but can be a bit buggy. It also seems to be a very cluttered way of doing it... I was wondering if anyone had any suggestions?
Cheers.
Re: PHP & MySQL site login, security concepts
Posted: Tue Dec 08, 2009 7:26 am
by batfastad
I had the form submitting to itself.
Then if count($_POST) is > 0... attempt the login.
Then I set any errors to a variable and output that above the login form (in a Heredoc block) so they can try again.
Rather than sending them to a separate page and needing them to press a back button.
For other forms on this particular project I've used jQuery AJAX to show the error messages but for the login I wanted something that can degrade a bit better.
Hope that helps
Re: PHP & MySQL site login, security concepts
Posted: Tue Dec 08, 2009 7:34 am
by timWebUK
Ah OK that makes sense. Quite a clever way of doing it. Never would have thought of that.
I will consider it on my next update, but it would mean changing a lot of the structure of my current application. I'm also new to heredoc's, just did some reading, but I can't understand the benefit of them? Why not just output a string regularly?
Cheers.
Re: PHP & MySQL site login, security concepts
Posted: Tue Dec 08, 2009 7:58 am
by batfastad
I love Heredocs (and just found out there's a new thing with PHP 5.3 called Newdoc)
What I tend to do is build my page full of all the variables, then echo that out at the end of the script in one go.
Rather than calling echo 'blah' etc loads of times
Lets me keep all the logic of the PHP script at the top, and the layout/output in one big Heredoc block near the end.
There is probably a marginal performance penalty though:
Code: Select all
echo <<<HTML
Here is some <b>HTML code</b> and a variable $var
HTML;
echo "Here is some <b>HTML code</b> and a variable $var";
echo 'Here is some <b>HTML code</b> and a variable $var';
So the top and middle ones, $var will output the value of $var
The bottom one (single quote marks) will literally output $var. That is because PHP doesn't parse for PHP variables within single quoted strings, whereas it does with Heredoc and double-quoted.
So if you don't have any variables in a string, you're wasting a small amount of server resources with the top 2 examples so you may as well use single-quoted.
I use double quoted for when there's a whole bunch of variables I want in a single line
Single quoted for when there's no variables (or I just concatenate the output eg...
Code: Select all
echo $var.' is brilliant but '.$foo.' is rubbish';
)
Heredoc when I'm building a good few lines of HTML code
And PHP's Newdoc is designed to be a single-quote equivalent of Heredoc... so variables won't get parsed in a Newdoc but will in Heredoc.
So I'll be using Newdoc when I need to output HTML layouts with no variables... once PHP 5.3 gains more traction of course
I'm no expert - that's just the convention I've sort of adopted over the years and its stuck!
Hope this helps

Re: PHP & MySQL site login, security concepts
Posted: Tue Dec 08, 2009 8:06 am
by timWebUK
Cheers! That's helped a lot actually, and given me an idea on how to implement something else I'm working on.