Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
I am at the point at my current website that I'm happy with it's functionality but still desire a better way to do things. To get an understanding, if I want to delete an uploaded photo I have to delete the MySQL entry manually and then delete the photos from their respective directories. It's slow but not something I need to do often, just something I did a lot in testing the scripts and stuff.

I did some research and it seems the new standard is crypt() and password_hash(). They create a salt automatically as well. That plus a login attempt limiter will help with brute force attempts. WikiHow has this article on creating a secure login with PHP & MySQL. They say I need to protect against the following:

  • SQL Injections
  • Session Hijacking
  • Network Eavesdropping
  • Cross Site Scripting
  • Brute Force Attacks


My only point of SQL Injections would be the username and password right? As long as I strip and sanitize the input I'm safe?

Session Hijacking is mostly a cookie thing right? I'm not planning on setting cookies for logging in/staying logged in. My site is purely PHP & HTML.

Network Eavesdropping is something I am worried about. Mostly because I am on a shared host. Even if I move to a dedicated, it's a "VPN" on a shared dedicated; I may have my own IP but the resources on the server are shared and traffic within this server geolocation is not encrypted and other VPNs can supposedly read it. Not sure if it's the same idea on my current shared hosting. Eventually my goal is to eventually charge for the websites services (and as user count goes up) and I'll be able to move to a proper dedicated server. But, I have other hurdles to face long before that happens. I plan on 2-3 years before seeing an interest and maybe 3-4 years before moving to a real dedicated server.

I believe Cross Site Scripting is of little concern since my site doesn't utilize JavaScript, just PHP & MySQL. For now. Obviously, I want to code this in for future proofing but it's not huge on my priority list. However, is XSS something that can still affect me? I remember XSS being a huge issue with Facebook, but again that site uses much more than the languages I'm using here.

Again, brute force isn't something I'm overly concerned about because I feel like I have that fairly well covered. Is there anything I'm missing though? What's the proper way to store logins? I don't plan on keeping the salt hashes on the same table as the user credentials for security reasons. Is this the proper way to do this? For a site that'll have 2, maybe 5, users would be ideal to have a hard coded salt in the PHP? I realize it makes the passwords less secure though.

Again, this script is just for me. Eventually it'll be for, at most, 5 users and I don't expect any of this to be a huge problem. It doesn't mean I will not be prepared nor turn a blind eye towards. The script WikiHow provides is too much at once, it doesn't take the time to explain anything and I'm not a fan of copy-paste; I like to research functions and write my own code with my own verbose comments.

Any insight, anecdotes, tips, and resources are appreciated!
comicIDIOT wrote:
WikiHow has this article on creating a secure login with PHP & MySQL.
Looks generally reasonable. Their attempt limiter is rather dumb; I'd prefer to limit it for attempts from a tuple of IP address and account, since otherwise it's trivial to launch a denial of service attack against a selected user.

Quote:
My only point of SQL Injections would be the username and password right? As long as I strip and sanitize the input I'm safe?
Anywhere you take user input and touch the database. Just be sure you escape inputs, ideally with an API that automatically does so (I assume PHP provides some API that's more sophisticated than "build a string manually and throw it at the database"..).

Quote:
Session Hijacking is mostly a cookie thing right? I'm not planning on setting cookies for logging in/staying logged in. My site is purely PHP & HTML.
You still need a cookie to authenticate a UA, even if it's cleared at the end of a session. Encryption is the real solution (see below).

Quote:
Network Eavesdropping is something I am worried about.
HTTPS.

Quote:
Cross Site Scripting
Again, sanitize anything that comes from a user. If a user can put something in that ends up in your HTML, they have a potential avenue to embed scripts from anywhere they like and as a result execute code within your page's context (permitting things like stealing session cookies or deleting everything the user has permission to delete).

Quote:
What's the proper way to store logins?
Just use password_hash(). The default options should be fine, since it's bcrypt. No point is splitting salt/hash across multiple tables because it doesn't really give you any additional security, and the point of a salt is to make rainbow tables infeasible anyway.
Good idea on the limiter, I was planning to only have it per user but adding in the IP would also be smart. Thinking forward, it'd be wise to log IPs for a period of time and if I get too many failed attempts from the same range, then block that.

SQL Injections seems as straight forward as I thought.

Session Hijacking & Network Eavesdropping will be hard. I've moved to a shared host to get things running and am truly loving it for now. Sadly, the HTTPS costs $70 a year and HTTPS access to my sites is blocked. I've been looking into whether I can use a freebie certificate in place but I have only spent about 5 minutes on it over a few weeks.

Pretty much the only input a user has to the page is pictures from their phone. Upload photo and it shows. I'm making this management page so photos can be deleted. All they'll see is the image thumbnail, unique/page ID, and the original image name. There will be a check box and a delete button. That's really all I'll have for now. Since this will also double as the page where I manage my photo portfolios, I'll be able to type in new portfolio names but it won't show up directly in HTML, the script will grab the portfolio names and then search photos for matching keywords and display relevant photos.

I thought the point of a salt was to add a predefined start/end to a password before it got hashed. Why store the password and salt together? I thought the salt made the encryption stronger? The php.net explanation visibly shows where the salt lies within the output. If the salt is randomly generated each time, how do I check against the existing salt+hashed-password?

Edit: Could I substitue sessions for cookies? I don't really have anything against cookies but I'm just trying to weigh my options. Or, do I use sessions along side cookies? I've done some reading since discovering sessions and cookies seem rather primitive. I see the leisure in having the client computer store the credentials but I give up direct control, if they sign out I just delete the cookie but if they idle for 30 minutes the cookie is still valid where as I can terminate a session. I also (apparently) open myself to manipulation of that cookie, so I presume I would need to sanitize the cookie contents as well.

Since sessions are preferred for short term situations, I feel like it'd be the best course to take.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement