a few things

[Ninjakreborn]

Here are some things I was thinking, I wanted advice on.
I am recently starting to do log in pages, I already know everything about how to do them, anyway, sessions, cookies, databases, whatever.
What I want to find out, is my current idea was to use the database to pull the information and check it to make sure it's valid, registering them into session variables, and using that throughout the site, for authentification, what are the chances of a session hijacker, is it as big of a deal as some of the books made it out to be.
If ebay for instance did it that way, would it get hacked all the time, or is it a good idea to never use sessions, just looking for a little insight before I start stepping into this.

[cmgmyr]

Why don't you combine sessions and cookies. Then you shouldn't have anything to worry about.

-Chris

[kalivos]

If I'm not mistaken, ANYTHING you use has the possibility of being hijacked. I personally use Sessions as it's an easy thing to do. I suppose you could register an ID with their IP address, but doing so may cause more headaches then help. IP addresses are preaty unreliable.

In response to Chris: I thought sessions were cookies, no? From what I understand, sessions store the data on the server and give you an ID in a cookie.

[redarrow]

If you dont put session information like the email password there fine enjoy.

[redarrow]

sessions use cookies but when cookies are disabled they use there self lol..............



Also businessman you no that if someone wants it they will get it.

always close all front doors and backdoors.

[cmgmyr]

They are like cookies...but not. Cookies are stored on the user's computer and sessions are on the server. So if you have information getting checked all of the time from 2 different sources you shouldn't have anything to worry about.

[pixy]

You could always make a function that stored the user's md5($_SERVER[HTTP_USER_AGENT']) in a cookie when they log in, and check it against the actual user's md5($_SERVER[HTTP_USER_AGENT']) while browsing. Chances are there will be some sort of difference between them if the account is hijacked, and then you can kick them off.

[redarrow]

Pixy thats terable man if the user say turned off javascript then that user got no account.

[pixy]

^ Since when would turning off javascript not let you log the user's HTTP_USER_AGENT? Or am I missing something here?

[redarrow]

HTTP_USER_AGENT i thort you would use the HTTP_USER_AGENT with an array then insert informtion within the database then you do a check to see if the HTTP_USER_AGENT match if not chuck them off but the HTTP_USER_AGENT holds all the users browser information so there fore if the user turned of javascript then there chucked off.


no?

[pixy]

Umm, your sentance is one big run-on and I am not sure if I even understand what you are trying to convey.

Here's what i'm saying.
- Set a cookie with an encrpyted version of their HTTP_USER_AGENT information upon log in.
- Check that the HTTP_USER_AGENT on loggin in the cookie is the same as the current HTTP_USER_AGENT.
- If they dont match, say bye bye

The point is, they have to go through the log in process to get the HTTP_USER_AGENT cookie set on their computer and have it match the one they actually are. If someone "steals" someone's session, chances are either the cookie for HTTP_USER_AGENT won't be set because they didn't log in, or it won't match the one in the session.

I'm pretty sure javascript doesn't have anything to do with it...

Here an example:
if (isset($_SESSION['agent'])) {
    if ($_SESSION['agent'] !== md5($_SERVER['HTTP_USER_AGENT'])) {
        die ('You suck.');
    }
}

$_SESSION['agent'] is set on login like so:
$_SESSION['agent'] = md5($_SERVER['HTTP_USER_AGENT']);

Am I rambling?

[wildteen88]

Everthing about the user agent is sent in the header of each page request. It doesnt metter whether you have javascript on or off. As it doesn't use javascript to get the useragent. It is all sent in the header of each page request.

[redarrow]

so i can not use my account in a internet cafe no?

sorry but i still say the idear for that code will restrict a user to use there account sorry.

I think that businessman should use session as normal and valadate the code properly.

when it comes to a website going to be hijacked there are thousands of ports that any one can get in even with a firewall installed so i wouldnt worry just valadate data.

[Ninjakreborn]

Sounds good, so I was going to call the data from the database, and check if the username and password are correct, register the username and password into sessions, and run them at the top of each page, without them initialized then the pages don't get viewed, I will set a decent max lifetime, but not rediculous.
I am trying to learn about encoding and decoding
I know mysql has encode, decode functions, but everything with php is irreversable, I need the features, for them to be able to retrieve lost passwords, so inretrievable methods are unacceptable
what is this going to do, is this worth it, if so which one would be the key I create and use during decrypting

Encryption
[code]<?php
    srand((double)microtime()*1000000 );
    $td = mcrypt_module_open(MCRYPT_RIJNDAEL_256, '', MCRYPT_MODE_CFB, '');
    $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
    $ks = mcrypt_enc_get_key_size($td);
    $key = substr(sha1('Your Secret Key Here'), 0, $ks);

    mcrypt_generic_init($td, $key, $iv);
    $ciphertext = mcrypt_generic($td, 'This is very important data');
    mcrypt_generic_deinit($td);
    mcrypt_module_close($td);

    print $iv . "\n";
    print trim($ciphertext) . "\n";
?> [/code]

Decryption
[code]<?php
    srand((double)microtime()*1000000 );
    $td = mcrypt_module_open(MCRYPT_RIJNDAEL_256, '', MCRYPT_MODE_CFB, '');
    $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
    $ks = mcrypt_enc_get_key_size($td);
    $key = substr(sha1('Your Secret Key Here'), 0, $ks);

    mcrypt_generic_init($td, $key, $iv);
    $ciphertext = mcrypt_generic($td, 'This is very important data');
    mcrypt_generic_deinit($td);

    mcrypt_generic_init($td, $key, $iv);
    $plaintext = mdecrypt_generic($td, $ciphertext);
    mcrypt_generic_deinit($td);
    mcrypt_module_close($td);

    print $iv . "\n";
    print trim($ciphertext) . "\n";
    print trim($plaintext) . "\n";
?> [/code]
I think these will be good, because I can use it with passwords, credit card numbers, session id's and everything.

Also what about permanent ssl connection, routing it to where even when people type www.whatever.com or http://www.whatever.com into the browser, it redirects automatically to https://www.whatever.com are there downsides to ALWAYS using ssl, if not then why doesn't more people already use it this way, I have been confusing about that, I don't mean ssl for like 3 pages for some forms, but instead the entire website, will that decrease my chances of session hijacking?

[redarrow]

Most users use a third party credit card payment method as the name paypal is a well known payment method and trusted so users like the name paypal or other.

I dont think that theres a lot of user ssl becouse of the fact they use a 3rd party credit card payment method.

in saying that if you the website has got to take address info and high end information then that page needs ssl.

In the responce of using ssl and why is it not used by meny others, well the truth in the puding i trust paypal so i will shop with that website.From paypal i use ipn to get all the information that is personal therefore i dont need to use ssl do i.

ps. ssl does get used on pages that you dont see as you have not got a account for example a exclusive sex site there millons for downloading and so on................


remember as you get programming for a time you make programs to sell and the programs you sell have not got the abilty to let the user to alter the code they dont sell as good as a uncrypted code ok.

You must also remember that a crypted code is a code that a person going to look at and say what that mean and eventully a hacker or programmer comes along and uncrpt your work no point.


i do recomend that you goto zend.com and have a look at whats on offer and you can if you want to lock a domain name to your code ok.

[pixy]

[quote author=redarrow link=topic=100914.msg398867#msg398867 date=1153163656]
so i can not use my account in a internet cafe no?

sorry but i still say the idear for that code will restrict a user to use there account sorry.

I think that businessman should use session as normal and valadate the code properly.

when it comes to a website going to be hijacked there are thousands of ports that any one can get in even with a firewall installed so i wouldnt worry just valadate data.
[/quote] To be honest, you are REALLY not getting what I'm talking about. When you log in it sets the session, it doesn't matter where you are. Whatever, I'm tired of explaining it. The point is, you won't have any problems using the site unless you're trying to use someone elses's session.

As for resetting passwords, here's what I do:
- Encrypt with SHA() in the database (so that way, even if someone gains access the secure information can't be decoded).
- When they log in, check the SHA() version of their input against the DB to see if they match.
- When they forgot their password, randomly generate a new one and SHA() it into the database and send them and email with the random string so they can log in and change it.

Much safer than actually storing passwords in their unincrypted forms. If you can decrypt it, it means a hacker can decrypt it--and I would suggest against storing the password in a session. Why would you even need it there?

[Ninjakreborn]

I was going to call the username and password, test it, set it in sessions username and password, test them on each page using sessions, and if they don't exist, don't show the page.

[pixy]

If someone takes someone's session, then both of those things will be set and they will match. That doesn't really improve security.

Look at this page towards the bottom when he talks about HTTP_USER_AGENT. THAT is what I was trying to explain...
http://phpsec.org/projects/guide/4.html