requestmysql?

[Inverness]

How secure is comparing an MD5 result, as the password?

[projectigi]

well i dont know if u can use md5 because its one of this one-way encryptions, but i think at a php file you have to write the unencrypted password in...
or you could just connect at the php file and make a database for passwords

[SilentOne1988]

MD5 is NOT a form of encryption.
http://en.wikipedia.org/wiki/Md5

[Inverness]

Originally Posted by SilentOne1988

MD5 is NOT a form of encryption.
http://en.wikipedia.org/wiki/Md5

I already know that. I asked if MD5 comparison was a simple but relatively safe method?

[Maniaman]

Any plans to enable this function anytime soon?

[linkoraclehero]

First off, you DON'T need to send the password OR username, you make a config PHP file for that; Sending ANYTHING as get vars (The vars after ?, seperated by &s), is INSECURE, and downright retarded. Second, MD5 is hashing, it is one way, and it's common sense how you use it, no word will hash the same way, so you just hash both and compare. If you don't know about SQL Servers, don't even try them, just use scripted databasing. If you got your own SQL server, create an account that can only send INSERT and SELECT, that's all you need to add and read from a database.

[Skyld]

Originally Posted by linkoraclehero

First off, you DON'T need to send the password OR username, you make a config PHP file for that; Sending ANYTHING as get vars (The vars after ?, seperated by &s), is INSECURE, and downright retarded.

Eh, it is not really any more or less secure than opening a socket to your sql server and shooting data down it.

[linkoraclehero]

It's very insecure, get data can be read by anyone, thus anyone seeing the username and password can use a database manager to hack in, whereas using a PHP file, your using serverside vars, noone can see them, And the only accesses that can be made are serverside.

[Skyld]

Originally Posted by linkoraclehero

It's very insecure, get data can be read by anyone, thus anyone seeing the username and password can use a database manager to hack in, whereas using a PHP file, your using serverside vars, noone can see them, And the only accesses that can be made are serverside.

That was not really my argument; my argument was about sending GET variables as a part of a HTTP request.

[linkoraclehero]

GET vars are always insecure, no matter the case.

[JkWhoSaysNi]

Yeah, while you could use php as a way to access mysql it's not secure using GET vars and sending whole queries is very insecure since anyone who had access to the script could manipulate the database. Of course sending the password as a GET variable could make it slightly more secure if someone just had the script, but if you were connecting from graal clientside someone could just use a packet sniffer and get the info.

If you're going to access mysql through graal via php you should check the IP address of the person who called the script. This way you can limit it to the graal server getting access to your database. Of course this would make it impossible to connect to your database from a clientside script.

I thought it was
requestmysql(server,account,password,database,quer y);

That would be a terribly inefficient way of connecting to mysql since it would make a new connection to mysql every time it performed a query.

Keep in mind too, that querying mysql on another machine is, in most cases, going to be slower than creating a database npc to do the job.

[linkoraclehero]

It isn't ENTIRE insufficient, but it would be like making a bunch of pages that are used to grab one var each, then loading all those pages at once..... It'll work normally, causing lag on slower servers

[linkoraclehero]

As I just posted in the main board, seems requesthttp's 3rd argument can be of some use to checking if Graal is the requestee. That would mean you can only do the coding IF the client is accessing through graal. I'll be working on getting my account info in a database, on www.bladestrife.net/nsc/user.php

[JkWhoSaysNi]

Actually I found a way to help detect whether it's graal or not.

Graal does not set most of the HTTP variables. HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT_CHARSET, HTTP_KEEP_ALIVE, HTTP_CONNECTION are all not set by graal, you could check to make sure these are all not set in your php script.

That should be enough to stop most wannabe hackers. Of course it would be possible to mimick this behaiviour using cURL or through another scripting like php or perl (WWW:mechanize could do this with ease, unfortunatly).

If functionaility was brought in so we could set one or more of these variables ourselves we could make it a lot more secure because we could use these values as checks. You could set them as something in graal and check them in your php script. (of course doing this from clientside would still leave it open to packet sniffing, but no moreso than a requestmysql() function.)