SimpleBB - Completely Re-engineered

[s-p-n]

They say a picture's worth 1,000 words..

You're not ready to switch to cookies yet for you don't understand them. I think your little "Hack attempt detected" message is cute, but it sure is easy to get passed!

[Check attachment]

I don't know what Tony's PW is, but I know it's not "demo", and I also know I don't need to know it to access his account. If you had any kind of features I'd be able to edit/delete his posts and update his account.. But you don't, so.. there's not much I can do except add more threads/posts.

Get "Web Developer" and "Firebug" for firefox.. Oh, and for the 50th time, please find an alternative to the <center> tag... It's really not helping your cause if you can't figure out how to use mathematics to center elements instead of deprecated, faulty, text centering methods.

Here's a little trick:

margin-left:auto;
margin-right:auto;

[xSilv3rbullet]

They say a picture's worth 1,000 words..

You're not ready to switch to cookies yet for you don't understand them. I think your little "Hack attempt detected" message is cute, but it sure is easy to get passed!

[Check attachment]

I don't know what Tony's PW is, but I know it's not "demo", and I also know I don't need to know it to access his account. If you had any kind of features I'd be able to edit/delete his posts and update his account.. But you don't, so.. there's not much I can do except add more threads/posts.

Get "Web Developer" and "Firebug" for firefox.. Oh, and for the 50th time, please find an alternative to the <center> tag... It's really not helping your cause if you can't figure out how to use mathematics to center elements instead of deprecated, faulty, text centering methods.

Here's a little trick:

margin-left:auto;
margin-right:auto;

WOAH.
That's bad.

Forgot all about cookie vulnerabilities. T_T

---------- Post added at 07:13 PM ---------- Previous post was at 05:44 PM ----------

Patched.
Try it now. :P

[jMerliN]

WOAH.
That's bad.

Forgot all about cookie vulnerabilities. T_T

---------- Post added at 07:13 PM ---------- Previous post was at 05:44 PM ----------

Patched.
Try it now. :P

Why are you using cookies at all?

[xSilv3rbullet]

Why are you using cookies at all?

Aren't they supposed to be better for nonsensitive stuff?

Also, because i can control sessions better?
:O

[jMerliN]

Aren't they supposed to be better for nonsensitive stuff?

Also, because i can control sessions better?
:O

They are made completely useless by server-side session states. The only thing you could make an argument for us making a cookie to hold a session id key you store in a table somewhere the authenticates the person so they don't have to log-in at every visit of your forum. Anything outside of that is much more easily done (and makes more sense to do) using session variables on the server.

[xSilv3rbullet]

They are made completely useless by server-side session states. The only thing you could make an argument for us making a cookie to hold a session id key you store in a table somewhere the authenticates the person so they don't have to log-in at every visit of your forum. Anything outside of that is much more easily done (and makes more sense to do) using session variables on the server.

The only cookies I'm storing are the user id, user name, and user session.
THe session makes sure that the exploit spn showed doesn't work.

[jMerliN]

Why are you storing username and id?

[xSilv3rbullet]

Why are you storing username and id?

Hmm...good point.
Maybe not username

I could just update the session each time.

ID is kinda obvious lol...or not
In the sessions MySQL table, i have user id, so i could just select the user id and update it each time...?

[Exiled Hero]

Why are you creating the $sql object over and over again when you have included functions.php?

If you have created the $sql object in fucntions.php and include it, your other files will inherit it.

You have also created the object more than once inside the same file. it isn't needed. Once created, it can be used over and over.

    $sql = new SQL();

    $usrnm = $sql->protect($user);
    $password = $sql->protect($pass);
    $ptitle = $sql->protect($title);
    $pmessage = $sql->protect($message);
    $pposter = $sql->protect($poster);
    $pisthread = $sql->protect($isthread); 

Would save execution time and less code.

$conn = @mysql_connect($host, $user, $pass);
$db = @mysql_select_db($db, $conn);

if(!$conn || !$db)
{
    die("Error connecting to the database.");
} 

Could of been..

$conn = @mysql_connect($host, $user, $pass);
$db = @mysql_select_db($db, $conn) or die("Error connecting to the database."); 

be the same as above, just less execution time.

[s-p-n]

What data is used to make the hash for sbbsession?

Oh, and storing the user ID/username (either) is pointless or insecure. All you should need is a hash of the user+pass, (such as sbbsession, maybe). Nobody can crack that without knowing the user+pass, and they wouldn't need to if they did. It's simple.......... SO SIMPLE!

In fact, wait... Even That's redundant- to a point. You don't even need to hash the user+pass... Look, try a procedure more like this: [It's taboo to store raw password data in cookies, but someone actually has to steal their cookies for the particular site in order to get it. If a user is that insecure, technically they shouldn't be ENTERING a password in the first place.]

- User enters site.
- If Session[user] & Cookie[pass] are defined
- - continue
- else :

- - If Post[user] & Post[pass] are defined
- - - Cookie[user] = Post[user]
- - - Cookie[pass] = Post[pass]

- - If Cookie[user] & Cookie[pass] are defined
- - - Session[user] = sql_escape(Cookie[user])
- - - Session[pass] = md5(Cookie[pass])

- check_user_data(Session[user],Session[pass])

check_user_data returns the number of rows for a query that selects an id from the users table where user+pass are equal to their alter-ego session values.

If true, the user is seen as logged in. False, they are not logged in as anyone. No silly "Ah, being hacked!" messages, they're just immature. Also, there's no purpose for those lines in any application that doesn't expect to be getting hacked.

Since the cookies+session values are always the same (this should be declared at the top of all pages), then you only need to check the one with highest priority. Cookies are optional, if the user ticks the box that says "Remember Me", then they get a couple extra cookies, otherwise they only get the PHPSessID cookie.

The purpose of the cookies are solely for keeping a user logged in after the session is over. So if they visit your site with cookie variables, then they get turned into session variables, and cookies are never heard from again until the next time a session is created. That's why I chose to make them literally, identical of the form variables submitted.

If for whatever reason you change the way you encrypt the password or whatever, people who come back with user+pass cookies won't notice any problems, because the user+pass are compliant with the log-in form, and everything gets turned into Session[name]. All you'd have to change is the session variables, because they're the most reliable, and will surely have the data we need, whenever present. That data will come from the client [as GET, POST, or COOKIE]. But it will be escaped, in it's own way, before being compared with/inserted to the database in the form of a query.

Security is a breeze, just recognize every single point that makes a program insecure- that is, wherever the client can manipulate (or even view in some cases) ANY data on your server.

[xSilv3rbullet]

What data is used to make the hash for sbbsession?

Oh, and storing the user ID/username (either) is pointless or insecure. All you should need is a hash of the user+pass, (such as sbbsession, maybe). Nobody can crack that without knowing the user+pass, and they wouldn't need to if they did. It's simple.......... SO SIMPLE!

In fact, wait... Even That's redundant- to a point. You don't even need to hash the user+pass... Look, try a procedure more like this: [It's taboo to store raw password data in cookies, but someone actually has to steal their cookies for the particular site in order to get it. If a user is that insecure, technically they shouldn't be ENTERING a password in the first place.]

- User enters site.
- If Session[user] & Cookie[pass] are defined
- - continue
- else :

- - If Post[user] & Post[pass] are defined
- - - Cookie[user] = Post[user]
- - - Cookie[pass] = Post[pass]

- - If Cookie[user] & Cookie[pass] are defined
- - - Session[user] = sql_escape(Cookie[user])
- - - Session[pass] = md5(Cookie[pass])

- check_user_data(Session[user],Session[pass])

check_user_data returns the number of rows for a query that selects an id from the users table where user+pass are equal to their alter-ego session values.

If true, the user is seen as logged in. False, they are not logged in as anyone. No silly "Ah, being hacked!" messages, they're just immature. Also, there's no purpose for those lines in any application that doesn't expect to be getting hacked.

Since the cookies+session values are always the same (this should be declared at the top of all pages), then you only need to check the one with highest priority. Cookies are optional, if the user ticks the box that says "Remember Me", then they get a couple extra cookies, otherwise they only get the PHPSessID cookie.

The purpose of the cookies are solely for keeping a user logged in after the session is over. So if they visit your site with cookie variables, then they get turned into session variables, and cookies are never heard from again until the next time a session is created. That's why I chose to make them literally, identical of the form variables submitted.

If for whatever reason you change the way you encrypt the password or whatever, people who come back with user+pass cookies won't notice any problems, because the user+pass are compliant with the log-in form, and everything gets turned into Session[name]. All you'd have to change is the session variables, because they're the most reliable, and will surely have the data we need, whenever present. That data will come from the client [as GET, POST, or COOKIE]. But it will be escaped, in it's own way, before being compared with/inserted to the database in the form of a query.

Security is a breeze, just recognize every single point that makes a program insecure- that is, wherever the client can manipulate (or even view in some cases) ANY data on your server.

You make it seem so easy. lol :P

The time that the session was created is stored in the MD5 hash.

[s-p-n]

You make it seem so easy. lol :P

The time that the session was created is stored in the MD5 hash.

Because it IS easy.

You're just making it too hard. The time is not relavent, a user can define a time, and create an MD5 pass of it. It's very unlikely anyone will figure it out to the second, but it IS possible to crack without a traditional key, known as a password.

Also, your query for loading user data should look sort of like,

..'WHERE user = "'.$_session['user'].'" AND pass = "'.$_session['pass'].'"' 

[xSilv3rbullet]

Because it IS easy.

You're just making it too hard. The time is not relavent, a user can define a time, and create an MD5 pass of it. It's very unlikely anyone will figure it out to the second, but it IS possible to crack without a traditional key, known as a password.

Also, your query for loading user data should look sort of like,

..'WHERE user = "'.$_session['user'].'" AND pass = "'.$_session['pass'].'"' 

If they make up the time, they don't get access.

Flow:

Login
->
time() is hashed and inserted into mysql table, along with the userid and normal time
->
sbbsession is set (md5 hashed time)
username is set
id is set
->
each pageload checks to make sure the sbbsesion and id are in the same row, and that the session is active, if not, it locks out the user.

It probably still is hackable some way, but not in a way that i can see. :p

[s-p-n]

I cannot believe you insist on using a "time()" function in place of a password.

Your procedures are redundant, and do not make sense.

It is insecure because the time "tony" logged in last could be either achieved, if not guessed. If you don't believe a hacker could create an MD5 [or whatever hash used] of a time-stamp, you're in denial of the worst kind. The timestamp should be used to show an online/offline graphic for each user, it shouldn't be used to log that user in.

When logging in, does the user enter their ID and a timestamp? No, they do not. That would be silly. They enter a user and a pass, because it's a standard and recognizable way of logging in. It's normal, casual, and seems secure. The user understands, "I keep my password safe so I don't lose my account data."

Not only are you making your scripts run slower, but you're putting the very trust you may have with your users on the line when doing things differently just for the sake of being unique, or whatever the purpose may be. That's the concept I'm going to use in order to reach you. Look at things that work.. Like Windows, Servers, games, secure web-sites, banks- things that work.

They all follow a very simple procedure for security. A visible username (on a credit card, your credit card numbers), and a simple password. (on ATM cards, your PIN). Most things just use user+pass, but even when they don't, they use a very similar system for security. If the person knows the CC number and the pin, grant them access.

The biggest problem with credit and debit cards, is that some places don't ask for the pin, but instead a zip-code, or maybe nothing at all; just a quick swipe (which is basically just the numbers visible on the card). That's a problem because they don't use the stupid 4 digit PIN. It's like using a timestamp (zip-code) instead of a password (pin). It's unlikely, but achievable to figure out the zip-code/timestamp. Not as bad as asking for just the card number (or ID+user, in your previous issues), but still inferior a typical PIN number (or pass+user).

See, nothing replaces the simplicity of a password as the primary key for log-in credentials. Many huge corporations did it right, and many made very large mistakes. Learn from both.

[xSilv3rbullet]

I cannot believe you insist on using a "time()" function in place of a password.

Your procedures are redundant, and do not make sense.

It is insecure because the time "tony" logged in last could be either achieved, if not guessed. If you don't believe a hacker could create an MD5 [or whatever hash used] of a time-stamp, you're in denial of the worst kind. The timestamp should be used to show an online/offline graphic for each user, it shouldn't be used to log that user in.

When logging in, does the user enter their ID and a timestamp? No, they do not. That would be silly. They enter a user and a pass, because it's a standard and recognizable way of logging in. It's normal, casual, and seems secure. The user understands, "I keep my password safe so I don't lose my account data."

Not only are you making your scripts run slower, but you're putting the very trust you may have with your users on the line when doing things differently just for the sake of being unique, or whatever the purpose may be. That's the concept I'm going to use in order to reach you. Look at things that work.. Like Windows, Servers, games, secure web-sites, banks- things that work.

They all follow a very simple procedure for security. A visible username (on a credit card, your credit card numbers), and a simple password. (on ATM cards, your PIN). Most things just use user+pass, but even when they don't, they use a very similar system for security. If the person knows the CC number and the pin, grant them access.

The biggest problem with credit and debit cards, is that some places don't ask for the pin, but instead a zip-code, or maybe nothing at all; just a quick swipe (which is basically just the numbers visible on the card). That's a problem because they don't use the stupid 4 digit PIN. It's like using a timestamp (zip-code) instead of a password (pin). It's unlikely, but achievable to figure out the zip-code/timestamp. Not as bad as asking for just the card number (or ID+user, in your previous issues), but still inferior a typical PIN number (or pass+user).

See, nothing replaces the simplicity of a password as the primary key for log-in credentials. Many huge corporations did it right, and many made very large mistakes. Learn from both.

I think I kind of understand what you're saying, but how can I hacker get the exact time of the time that a user logged in?

For example, lets say i login at time() a.

a gets MD5d to lets say a1b2c3d4.

The hacker would first have to find the right value of sbbsession, and MD5 each attempt to try and get a1b2c3d4.

But I do know that this system has some problems, the system just got hacked again by a hacker.

And I wouldn't suggest MD5ing the password.
Easy text can be unhashed by using this:
http://md5decrypter.com/

Of course, not a very complicated password, such as 10cw3rxz_r3FTaflje.
But what kind of user would want to remember that?

Maybe I'll use two hashes: MD5(SHA1())...
But that might cause some performance issues.

I'll decide later. :P