DragonPrime - LoGD Resource Community
Welcome Guest
  • Good morning, Guest.
    Please log in, or register.
  • February 23, 2019, 07:40:45 AM
Home Forums News Downloads Login Register Advanced Search
* * *
DragonPrime Menu
Resource Pages

Pages: [1] 2 3 ... 10
 on: Today at 03:23:59 AM 
Started by RaynDarren - Last post by Sunday
I can volunteer my help.

 on: Today at 01:14:49 AM 
Started by RaynDarren - Last post by Aeolus
Only ever work with someone you know and trust. Never work alongside someone as if it's a job application. Who knows what they could do to your sites if they ever disagreed with you.

 on: Yesterday at 11:22:44 PM 
Started by RaynDarren - Last post by RaynDarren
Hi everyone,

It's been a while since I've posted and I've come back looking for help. I recently opened my own business, with 6 lotgd games hosted on and supported by me. to that end, I'm looking for another coder to come on board and help with bugs that may arise, write new modules with me or on their own and generally help to share the workload.

Everything is volunteer at this time, but compensation will be available within the year.

Anyone interested please contact me at sarah.hale@siteweaver.org or reply here.


 on: February 20, 2019, 04:46:26 PM 
Started by artti - Last post by pharis
from the top of my head, this could be a safer login approach ( assuming you added a username hash and encrypted the password at user creation )


//  get the name and password
    $name = httppost("name");
    $password = httppost("password");

//  hash the passed username , effectively neutralizing any potential fabricated unescaped content ( of course, you should always escape it first , one never knows )     
    $hashedName = hash('sha256', $name );

//  now look explicitly for it in the DB ( and for the locked flag ) , nothing else
    $sql = "SELECT * FROM " . db_prefix("accounts") . " WHERE hashedName = '$hashedName' AND locked=0";

//  process result
    $result = db_query($sql);
    $SomeNameVariable = db_fetch_assoc($result);

//  check content
    if ( !empty($SomeNameVariable) )
    #   the passed username exists and we found a hashed version of it -> lets check if the password matches ...
        if ( !password_verify( $password , $SomeNameVariable['password']))
        #   password does not match, revoke user here
            $session['user'] = FALSE;
        #   password did match
            $session['user'] = $SomeNameVariable;
    #   nothing found
        $session['user'] = FALSE; 

 on: February 20, 2019, 04:21:14 PM 
Started by artti - Last post by pharis
The bigger issue here is the fact that [ login = '$name' AND password='$password' ] is a receipt for disaster. I dont have the whole escaping code in that section in front of me, but it is a quite inviting attack vector right there, since you are querying the DB using what is passed by the user and not having any control about the format of what to expect, thus opening yourself to all sorts of attacks. I dont see anything in that code that is going to protect the DB against sql injection.

Now, since you must alter the login / user creation process in order to achieve better hashing / encryption anyway ( you have to save the password at creation in the new desired encrypted format ) , why not adding a couple of lines more and have it a bit more secure ?

My advice :

- when creating the user , encrypt the password with password_hash()
- create another hash using the username ( you can use whatever hash algorithm you want, but of course if possible skip md5() and sha1() and save it to that users row
- now, every time a user logs in, hash its username first, and then look for the same value in the DB ( if evil code has been passed , it is now harmless since it has been hashed and the query is "safe" )
- since the hash should be unique ( you really should not have 2 users with the same username ) , you load all the needed data from the found row
- at this stage, you can compare the real username and the password within the array, without querying the DB ( since you did that already )
- if all matches, go ahead and validate the user, if not ( or if a malicious code was passed as the username, nothing will really happen , maybe an warning ) just ignore the user and revoke access

This is not a thorough explanation or a fail safe golden sword that will solve all your problems, but since you are willing to touch that code section, it adds reasonable security.

Oh, and for gods sake, while you are at it, and if you need to compare hashes at any point ( that is not a password ) use hash_equals() ->  http://php.net/manual/de/function.hash-equals.php

 on: February 19, 2019, 02:34:44 AM 
Started by artti - Last post by artti

I want to go from md5() that we use in crypting passwords to new password_hash() that is more secure.


On the login.php page around line 33 is


$name = httppost("name");
$password = httppost("password");
$password = md5(md5($password));

$sql = "SELECT * FROM " . db_prefix("accounts") . " WHERE login = '$name' AND password='$password' AND locked=0";
$result = db_query($sql);

if (db_num_rows($result)==1) $session['user']=db_fetch_assoc($result);

would it make sense to go next route?

$name = httppost("name");
$password = httppost("password");

$sql = "SELECT * FROM " . db_prefix("accounts") . " WHERE login = '$name' AND locked=0";
$result = db_query($sql);
$SomeNameVariable = db_fetch_assoc($result);

$allCorrect = password_verify($password,$SomeNameVariable['password']);

if ($allCorrect) $session['user']=$SomeNameVariable;

or should I have first query just to get password hash from database where login = $name and then select again.

After writing this all out, it makes sense to have just one query, but what are your opinions?

 on: February 08, 2019, 05:25:00 AM 
Started by Annunakitty - Last post by pharis
i miss the graphics there ( i know that there are of course accessability concerns with graphics , but i still miss them thou )  ... looks a bit too dark. Do you have any others ?

 on: January 26, 2019, 11:46:47 AM 
Started by Annunakitty - Last post by Sunday
Good to see another template not follow the '90s design pattern of organizing with tables.

 on: January 25, 2019, 11:21:55 PM 
Started by Annunakitty - Last post by Annunakitty
So, I've spent a good chunk of the last couple days diving into Bootstrap, a VERY comprehensive CSS framework for making responsive pages.  I've completely redone the previous attempt and put a good amount of work into making a very basic console-style responsive template.

Full screen on desktop nets you a modest 3 column layout you will probably find familiar:

Smaller screens or resizing a desktop window will rearrange the Nav-Links below the page content, followed by the charinfo table:

It's not perfect, but shouldn't take too much more work to be able to officially submit to the download archive! Attached is the current build if you'd like to give it a try!  Let me know what you think?

 on: January 23, 2019, 11:31:25 AM 
Started by Annunakitty - Last post by Annunakitty
Thank you for the responses!  I'm still futzing with it, certainly not ready for a full release; the link colors are just plain ol default html colors so yea I'll fix that for sure.

Last night I spent a little while trying to css up some columns so nav is on the left and stats are on the right but this layout was being fickle so I may not end up actually using this specifically as a starting point for anything, BUT I will polish this up more to be released, perhaps as a potential replacement for the Console template.  Stay tuned!

Pages: [1] 2 3 ... 10

DragonPrime Notices
Version 1.1.2 is the current supported version and is available for download.

Support Us
No funds raised yet this year
Your help is greatly appreciated!
Recent Topics
DragonPrime LoGD
Who's Online
32 Guests, 0 Users
Home Forums News Downloads Login Register Advanced Search