Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[CS:DE] Website Server Status/Register


Odin
 Share

Recommended Posts

An easier way to do it might be to use a web language for authentication, send a GET request form the server like page.php?user=username&pass=password than have it give back a true or false after checking it against the sql database would require a lot less integration into the engine seeing as the database stuff happens in on the web server.
Link to comment
Share on other sites

@S.J.R.:

> This is why when I read that someone knows PHP, that I won't ever hire him or her, because he or she certainly lacks knowledge about cryptography & security.
>
> Yours faithfully
>   Stephan.

Looking at the first 3 tutorials on W3Schools.com is what all the pros do.
Link to comment
Share on other sites

@Scott:

> An easier way to do it might be to use a web language for authentication, send a GET request form the server like page.php?user=username&pass=password than have it give back a true or false after checking it against the sql database would require a lot less integration into the engine seeing as the database stuff happens in on the web server.

Hahaha. No.
Link to comment
Share on other sites

@S.J.R.:

> This is why when I read that someone knows PHP, that I won't ever hire him or her, because he or she certainly lacks knowledge about cryptography & security.
>
> Yours faithfully
>   Stephan.

Well that's like saying because some one is black they are lazy, eat watermelon and will never make anything of their life. It's just not true…

@Robin:

> Hahaha. No.

I understand its not the best most secure idea, but its easy and it seemed like that's what this OP was going for.
Link to comment
Share on other sites

@Scott:

> I understand its not the best most secure idea, but its easy and it seemed like that's what this OP was going for.

Video game development isn't easy. If you're going to go for the easy option and put your user's data at risk then you're stupid.
Link to comment
Share on other sites

@Scott:

> Well that's like saying because some one is black they are lazy, eat watermelon and will never make anything of their life. It's just not true…

That comparison is as illegitimate as what those people do: I am actually basing my opinion on what experience such a person would have, and you are telling me that is exactly the same as basing my opinion on their race. Thanks for being offensive to me. Yes, I do that take as an insult, and not lightly.

PHP is the most popular scripting language for scripting server back-ends for websites. The reason why that is, is because it is easily accessible. The majority of people who know PHP have clearly no idea about security & cryptography at all, you have just proven that yourself: using GET-variables instead of POST-variables to pass the user data to sign in. Some other common problems are: MySQL injection, cookie hijacking, session hijacking, man-in-the-middle attacks, brute-force attacks, dictionary attacks, unwanted file access, hashing passwords (yes, this is a vulnerability), etc. Almost everything I listed in there can be prevented, but generally is not when the website is scripted in PHP, and you are here telling me that, despite you making the same error, it is acceptable to do, and that I shouldn't ever refuse inexperienced people, **because it is exactly the same as refusing people because of their race**?

The second thing, is the fact that PHP is extremely slow. But as it isn't related to this thread in any way, I'll just leave that out.

Yours faithfully
  Stephan.
Link to comment
Share on other sites

@Scott:

> An easier way to do it might be to use a web language for authentication, send a GET request form the server like page.php?user=username&pass=password than have it give back a true or false after checking it against the sql database would require a lot less integration into the engine seeing as the database stuff happens in on the web server.

Using mysql_real_escape_string(), regulating requests and having a password variable would resolve all security risks. However, I don't recommend it.

@Scott:

> Well that's like saying because some one is black they are lazy, eat watermelon and will never make anything of their life. It's just not true…

This isn't true??

@S.J.R.:

> …using GET-variables instead of POST-variables to pass the user data to sign in.

Both GET and POST are the same security wise.
Link to comment
Share on other sites

**MySQL injection-** You can prevent this in code and setting up the database, limit access to that database so it only has access to the username/password than they can not get to any other information as that database login has no access to it.
**cookie hijacking**- Not even using cookies in that example…
**session hijacking-** Or sessions…
**man-in-the-middle attacks-** As long as you put some sort of encryption on it what's there to grab? I mean your passing the username/password over their connection both ways.
**brute-force attacks-**  So your saying every other method is immune to trying every combination? Everything will fall if you have enough computing power to break it in a reasonable amount of time.
**dictionary attacks-**  If the users password is in the dictionary then how is that my fault? So unless I have one of my passwords or keys as something in the dictionary than this is no problem.
**unwanted file access-** Not sure what to say about this.
**hashing passwords (yes, this is a vulnerability)-** Don't hash your passwords then.

Feel free to name off more

And I have no idea how those 2 examples are not the same, in both cases people where being discriminated based on something about them, now there not exactly the same obviously but its related. Your acting like no one uses php, when in fact this forum does… Are the people who programmed this forum to good for you to?

Side note:I'm very sorry if that offended you I'm not trying to make enemies please accept my apology!
Link to comment
Share on other sites

@Lenton:

> Both GET and POST are the same security wise.

They are not: POST is stored inside your HTTP request, GET is stored inside your URL.

@Scott:

> **MySQL injection-** You can prevent this in code and setting up the database, limit access to that database so it only has access to the username/password than they can not get to any other information as that database login has no access to it.

Yes, I know you can code it. Show me exactly _how_.

@Scott:

> **man-in-the-middle attacks-** As long as you put some sort of encryption on it what's there to grab? I mean your passing the username/password over their connection both ways.

This requires SSL and HTTPS, which a lot of websites seem to lack.

@Scott:

> **brute-force attacks-**  So your saying every other method is immune to trying every combination? Everything will fall if you have enough computing power to break it in a reasonable amount of time.

Wait one second before finishing the authentication request.

@Scott:

> **dictionary attacks-**  If the users password is in the dictionary then how is that my fault? So unless I have one of my passwords or keys as something in the dictionary than this is no problem.

Wait one second before finishing the authentication request.

@Scott:

> **hashing passwords (yes, this is a vulnerability)-** Don't hash your passwords then.

I don't, but everyone else hashes mine.

@Scott:

> Feel free to name off more

I don't really see a need to.

@Scott:

> And I have no idea how those 2 examples are not the same, in both cases people where being discriminated based on something about them, now there not exactly the same obviously but its related. Your acting like no one uses php, when in fact this forum does… Are the people who programmed this forum to good for you to?

It has to do with it being ethical or unethical. If you refuse someone because of his or her race, then that's unethical, and that can be considered discrimination, because it is, in fact, racism. If you refuse someone because of his or her experience, or more so his or her inexperience, then that is ethical, because seriously what is someone going to do who has no idea how to get the job performed?

I just told you: a lot of people use PHP, because they don't know better. Where do you see I am exactly saying that nobody does use PHP? And nobody did programme this forum, the author(s) scripted this forum, and I am quite disappointed about the product as a whole, and neither did I have anything to say when Marsh chose to use SMF, although there are no other options (because the majority of forums are scripted in PHP). And I would, in fact, programme my own forum in CGI/C, whenever I actually find the time to do so. But at the moment, I am busy with other more useful things such as programming my own library in C89, programming a new engine for you lot in C89 and programming my own game in C89, which are all perfectly combinable.

@Scott:

> Side note:I'm very sorry if that offended you I'm not trying to make enemies please accept my apology!

Well, apologies accepted, but do prevent it from re-occurring in the future.

Yours faithfully
  Stephan.
Link to comment
Share on other sites

This discussion has gone on enough. Ignoring Stephan is a very, very silly thing to do.

The Crystalshire registration system will not be released. If you need to ask for help in the first place then you're not experienced enough to be trusted with direct access to your forum's database.

I've already explained everything you need to do in-depth. You do not need to touch a single line of PHP.

For those arrogantly asserting how it should be done without the experience required to know what you're talking about - Shut up.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...