SitePoint Sponsor

User Tag List

Results 1 to 25 of 26

Hybrid View

  1. #1
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    How secure are sessions in php ?

    Does anyone know how secure sessions are in php ?

    Is it stored on the server ?
    If so, can it be retrievec by a third party somehow?
    If not, it must be stored on the client machine by PHP and encrypted I assume.

    Info and links from anyone who has dealt with this would be appreciated

    Cheers,
    Eli

  2. #2

    Join Date
    Oct 2003
    Location
    uroLand
    Posts
    1,340
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All the variables you store in the context of a session are stored on the server and are referred to with the session id. This id is a unique string, which identifies the client and is transmitted at each request (either as cookie or within the GET/POST request data). Now if a malicious user can get hold of this id he/she can take over the session. Such a case can be prevented if you store additional user/connection specific data with the session (browser, ip address,....).

  3. #3
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Normally stored as a file, though I shouldn't think that session data is encoded automatically though ?

    For passwords for example, use MD5. Also consider moving from files - default - to database.

    If your unsure, I seen an article over at php:arch Tried to upload the PDF, but it was way too big.

  4. #4
    No. Phil.Roberts's Avatar
    Join Date
    May 2001
    Location
    Nottingham, UK
    Posts
    1,142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By default, PHP session data is stored as a serialized array in a plain text file which is stored in the server temp directory. This has a number of security hazards as this directory is accessible to all users on the server.

    However it is possible to define a customer session data handler which can abstract the storage of the session info to a method of your choice.

  5. #5
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    hamburg, germany
    Posts
    103
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    php-sessions are vulnerable to fixation-attacks as outlined in
    http://de2.php.net/manual/en/ref.session.php
    -> http://www.acros.si/papers/session_fixation.pdf

    kai

  6. #6
    The Mind's I silver trophy Dark Tranquility's Avatar
    Join Date
    Sep 2003
    Location
    KSA - UAE
    Posts
    9,457
    Mentioned
    8 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by kaimeder
    php-sessions are vulnerable to fixation-attacks as outlined in
    http://de2.php.net/manual/en/ref.session.php
    -> http://www.acros.si/papers/session_fixation.pdf

    kai
    Quite intersting stuff !! thanks

  7. #7
    SitePoint Member
    Join Date
    May 2005
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    fingerprint scanner w/ php?

    i am new with php. how can i use finger print scanner with php?
    does it work to any fingerprint reader like the one in the ebay.com "Microsoft USB Fingerprint Reader"?

    i will gladly apprciate your response...

  8. #8
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by depaula
    i am new with php. how can i use finger print scanner with php?
    does it work to any fingerprint reader like the one in the ebay.com "Microsoft USB Fingerprint Reader"?

    i will gladly apprciate your response...
    This should be in a different thread, sessions and scanners are quite different. Do you know anything regarding the scanner technically? Do they provide some API's. Being Microsoft, it won't support PHP naturally via any API's it does provide, so you will probably need to use COM / .NET wrappers. However no one will be able to answer without knowing more about the scanner

  9. #9
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Looking breifly through the PDF, very interesting

    Learn something new everyday, need to read some more later but.

  10. #10
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's possible to use PHP sessions in a secure manner, as far as anything on the web is secure. Here's a brain dump of issues to watch out for though;

    1. Shared web servers - anyone else on the server can read your session files if PHP is running as an Apache module (so the session files belong to the web user). They (probably) won't know the site the sessions apply to but you may still be putting sensitive info (like credit card details) somewhere for all to see. Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache).

    2. XSS exploits and session hijacking - using JavaScript users can be fooled into giving away their active session_id. All someone needs to "hijack" a session is the unique session id. Research XSS and how to prevent it. Accept that session hijacking cannot be entirely prevented (using IP address for example is foiled by AOL, who assign a new client IP on more or less every page request) and double check "critical actions" a user can perform e.g. changing password - require the old password (which the session hijacker should not know). Displaying credit card infomation - do like Amazon and only display the last four digits. Etc.

    3. Session IDs in URL (and hijacking) - if you're using session IDs in the URL (as opposed to a session cookie), make sure offsite links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to elimate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts). Ideally, don't pass session ids in the URL - require users to accept a cookie if they need to "log in".

    4. Use SSL (HTTPS) - a session ID can be "sniffed" between the client and your server. If it's an app with money involved, SSL is a requirement. Otherwise you have to live with the risk.

    5. Don't use cookies for store sensitive information. Not really about sessions but I've seen people implement session-like behaviour using cookies. Cookie data, unlike sessions, gets stored on the client site. Apart from the "sniffing risk", a large majority of Windows users have little idea of security and may be "owned by haxor". Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistance (e.g. "Remember Me") rather than "active session" persistance.

    Brain empty for the time being.

  11. #11
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    It's possible to use PHP sessions in a secure manner, as far as anything on the web is secure. Here's a brain dump of issues to watch out for though;

    1. Shared web servers - anyone else on the server can read your session files if PHP is running as an Apache module (so the session files belong to the web user). They (probably) won't know the site the sessions apply to but you may still be putting sensitive info (like credit card details) somewhere for all to see. Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache).

    2. XSS exploits and session hijacking - using JavaScript users can be fooled into giving away their active session_id. All someone needs to "hijack" a session is the unique session id. Research XSS and how to prevent it. Accept that session hijacking cannot be entirely prevented (using IP address for example is foiled by AOL, who assign a new client IP on more or less every page request) and double check "critical actions" a user can perform e.g. changing password - require the old password (which the session hijacker should not know). Displaying credit card infomation - do like Amazon and only display the last four digits. Etc.

    3. Session IDs in URL (and hijacking) - if you're using session IDs in the URL (as opposed to a session cookie), make sure offsite links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to elimate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts). Ideally, don't pass session ids in the URL - require users to accept a cookie if they need to "log in".

    4. Use SSL (HTTPS) - a session ID can be "sniffed" between the client and your server. If it's an app with money involved, SSL is a requirement. Otherwise you have to live with the risk.

    5. Don't use cookies for store sensitive information. Not really about sessions but I've seen people implement session-like behaviour using cookies. Cookie data, unlike sessions, gets stored on the client site. Apart from the "sniffing risk", a large majority of Windows users have little idea of security and may be "owned by haxor". Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistance (e.g. "Remember Me") rather than "active session" persistance.

    Brain empty for the time being.
    Security is always a compromise between performance.
    • SQL Injection - [Resource] [example]
    • Obscurity - [Resource]
      • If there are any flaws in the design of the security, or the server is compromised this could reveal and expose private data.
    • Cookies - [Resource]
      • Sign Cookies over SSL as Secure.
      • Cookie Recipe [Resource]

        The recipe for our cookie follows easily from the hints presented in Section 3. We create an unforgeable authenticator that includes an explicit expiration time. We use HTTP state (i.e. cookies) to store this authenticator with the client. The value of this cookie is shown here:


        exp=t&data=s&digest=MAC(exp=t&data=s)

        Our cookie requires the use of a non-malleable MAC; that is, one where it is intractable to generate a valid ciphertext from a plaintext message related to a plaintext message with a known ciphertext [12, 24]. That is, no adversary can generate a valid ciphertext without both the servers secret key and the plaintext, no matter how many samples of valid plaintext/ciphertext pairs the adversary has. Examples of keyed, non-malleable MACs are HMAC-MD5 and HMAC-SHA1.
    • Encryption
      • This is usually where most security systems tend to fail. Usually allowing attackers to guess concatenated values by brute forcing the hash.

  12. #12
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Miami
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How much time is needed for somebody to sniff and then to use that info to hijack a session?

    I am confused on this whole thing but I have been playing with a system for our virtual store front. First off let me say it's just a userid and passwd that we send back and forth and the store front is only used for communications, ordering supplies, proofing etc. No dangerous info is exchanged.

    Here is our scenario.
    First off our customers are the only ones allowed in. We wanted a simple way to let them in so we created a flash swf movie and put a shortcut to it on their desk top. They basically enter their personal passwd and the swf then does some stuff.

    1. Generates a random number
    2. Uses that number to jumble up the passwd and userid hardcoded in the swf.
    3. Send the info to the server along with the random number jumbled along with the info.
    4. The server knows where to look for the random # and then how to uncode the jumbled info.
    5. If okay a temp passwd good for 30 mins is generated and sent back to swf.
    6. SWF then launches a browser window setting the userid and temppasswd which from then becomes the session passwd.

    I was thinking of taking it a step further and having the jumbling continue changing the tempass for every new page but since I dont even know how hijacking takes place this might be stupid.

    On the client side, the swf passowrd is entered using mouse clicks and I am looking for a way to get some computer info so its only good for that computer. I dont know what I should be looking for.

    This is all probably futile anyway, but I am interested how would this type of scenario be hijacked. Could they sniff the session password and unjumble it in time to use it?

    Thanks for your comments. If I have done something really stupid, it's because I keep reading how effective one solution is just to have someone else comment on it's vulnerability.

    PS. I know the swf can be grabbed from somebody in the clients office but if they go to that extent let them have it.

  13. #13
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    http://www.php-mag.net/itr/online_ar...odeid,114.html

    Just something I've found a minute ago, there is a link also at the bottom leading to the HTTP1/1 standard which might be useful to you.

  14. #14
    SitePoint Member
    Join Date
    Mar 2004
    Location
    Bulgaria
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi guys,
    reading these posts gave me another idea of session vulnerability. Maybe it is too obvious to you and that is why is not mentioned.
    Anyway I thought it was a good idea to share it.

    Imagine you work in a small web development company. You create websites using PHP and offer hosting on a server of your own. You are a small company that's why you can afford only one server. Your company is so small that if you don't reuse your code you will not finish your projects on time . You have created a beautiful PHP class for user login which you use on every website that you produce.
    Not so hard to imagine is it? You don't store the username and password of the user that is logged. You keep the UserID instead because you think it is enough and you don't want to store usernames and passwords in a file which can be read from anyone with access to the server, and you save one database request of course. If the UserID session variable is set then the user is logged.

    The question is:
    What will happen if someone logs to one of your websites where the registration is free for example, and then use his session_id when going to another of your websites having paid registrations?

    The session is there, the user is logged, the second website is hacked.
    I hope this will have someones eyes open
    And sorry if there is no way to have a programmer so stupid to fulfil all these factors

    The simple and obvious solution is storing the HTTP_HOST in the session as well.

  15. #15
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by naskovoto
    Your company is so small that if you don't reuse your code you will not finish your projects on time . You have created a beautiful PHP class for user login which you use on every website that you produce.
    Is your scenario that the different sites or applications use the same login class but the user data is stored in different databases? In that case, you should be able to go from one application to another and find yourself logged in as a different user, because the user ID belongs to someone else.

    If it's all in one database, then once you're registered on one site you should be able to simply go to the other site and log in as yourself. In that case, it has nothing to do with sessions, it's just a lack of adequately fine-grained access control.
    Dagfinn Reiersl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  16. #16
    SitePoint Member
    Join Date
    Apr 2003
    Location
    Croatia
    Posts
    14
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To reduce a chance of session hijacking you can generate fingerprint for each session ID and store it somewhere (i.e. mmcache's shm, filesystem) and in session variable

    You can generate fingerprint with md5 function:

    $fingerprint = md5($_SERVER['HTTP_USER_AGENT'].@$_SERVER['HTTP_ACCEPT_CHARSET']."secretword".$username);

    On each request you just compare session fingerprints.

    I'm using mmcache shm feature to store fingerprints together with last access time so I can handle timeouts and view how many users are currently visiting my site.

    Overhead is very little.

    As someone earlier mentioned you can write custom session handler, or even use mmcache's session store feature (if you can install it on your box)

    Cheers

  17. #17

    Join Date
    Oct 2003
    Location
    uroLand
    Posts
    1,340
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by el8
    To reduce a chance of session hijacking you can generate fingerprint for each session ID and store it somewhere (i.e. mmcache's shm, filesystem) and in session variable

    You can generate fingerprint with md5 function:

    $fingerprint = md5($_SERVER['HTTP_USER_AGENT'].@$_SERVER['HTTP_ACCEPT_CHARSET']."secretword".$username);

    On each request you just compare session fingerprints.

    I'm using mmcache shm feature to store fingerprints together with last access time so I can handle timeouts and view how many users are currently visiting my site.

    Overhead is very little.

    As someone earlier mentioned you can write custom session handler, or even use mmcache's session store feature (if you can install it on your box)

    Cheers
    http://www.sitepoint.com/forums/showthread.php?t=157291

  18. #18
    SitePoint Member jcesar's Avatar
    Join Date
    Sep 2003
    Location
    Colombia
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To secure a session look at the configuration file (or .htaccess)

    Quote Originally Posted by manual
    session.use_cookies boolean
    session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled).

    session.use_only_cookies boolean
    session.use_only_cookies specifies whether the module will only use cookies to store the session id on the client side. Defaults to 0 (disabled, for backward compatibility). Enabling this setting prevents attacks involved passing session ids in URLs. This setting was added in PHP 4.3.0.

    session.referer_check string
    session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string.
    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.12
    GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
    O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
    D++> G e+> h-- r- y+
    ------END GEEK CODE BLOCK------

  19. #19
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wouldn't think that using a *SWF file to register a username/password would prevent a session hi-jacking - as you've found out, it's a server-side issue

    As to how someone can actually hi-jack a session, have a good, long hard read of the page I posted earlier in this thread - explains (figure number 2) how a hi-jacking can be done, if you've not already read the article in question

  20. #20
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Wouldn't think that using a *SWF file to register a username/password would prevent a session hi-jacking - as you've found out, it's a server-side issue

    As to how someone can actually hi-jack a session, have a good, long hard read of the page I posted earlier in this thread - explains (figure number 2) how a hi-jacking can be done, if you've not already read the article in question
    Exactly...

    Firstly it does not matter how you connect the client to the server (or vice versa), whether this is using 'SWF', an Application, or browser. Regardless, of the medium used, never trust the client. Do not cache username/passwords or any private data on the client.

    Quote Originally Posted by whiterabbit

    How much time is needed for somebody to sniff and then to use that info to hijack a session?
    In order to hack a web-server generally 'foot-printing' the server to determine exploits or vulnerabilities occur somewhere along the line. After foot-printing a server and determining a vulnerability, a simple program can be created to automate, processes. Whether this be session hi-jacking or any other form. So the answer to your questions, is seconds. Note: you do not even need a program to automate this...

    Quote Originally Posted by whiterabbit
    Uses that number to jumble up the passwd and userid hardcoded in the swf.
    What do you mean HardCoded ("Flash can be decompiled")?

    Quote Originally Posted by whiterabbit
    SWF then launches a browser window setting the userid and temppasswd which from then becomes the session passwd.

    This is all probably futile anyway, but I am interested how would this type of scenario be hijacked. Could they sniff the session password and unjumble it in time to use it?
    Sounds like the session id is in the URL, which makes hi-jacking the session easier. [Examples + Resource]

    Quote Originally Posted by whiterabbit
    I am looking for a way to get some computer info so its only good for that computer. I dont know what I should be looking for.

    There are a few commonly used identifiers, however these have flaws too. (MAC ADDRESS | HARD DISK S/N | CPU ID | OS ID) Using a combination of these would help, and make it a little more difficult

    Off Topic:

    Why do I feel like i'm repeating myself

  21. #21
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Miami
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As to how someone can actually hi-jack a session...
    Good Article, I will have to read it a few more times to understand it better but it seems that if an attacker can get in to your server then you have lost anyway.

    Regardless, of the medium used, never trust the client. Do not cache username/passwords or any private data on the client.
    Okay. The idea was to protect against sniffing the password on an inta/internet and from spyware on the client so hard coding the pass was stupid, I know swf's can be decompiled.

    Sounds like the session id is in the URL, which makes hi-jacking the session easier
    No. The swf is only used for login and the jumbled passwd and id are sent using POST. After that the temp passwd is created and gets passed as a session variable.

    There are a few commonly used identifiers, however these have flaws too.
    I have to read the article again. It all starts to seem like a lost cause. We don't have that many clients, say 200. Is there another approach say like using a vpn...or ??

    We want it convenient for the client to login but we do not need to provide an easy means for registration. In other words we can physically access the clients computer to set something up.

    Sorry for the boring repitios subject, next time your in sunny Miami, I will buy you a beer

    Cheers

  22. #22
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by whiterabbit
    Okay. The idea was to protect against sniffing the password on an inta/internet and from spyware on the client so hard coding the pass was stupid, I know swf's can be decompiled.

    No. The swf is only used for login and the jumbled passwd and id are sent using POST. After that the temp passwd is created and gets passed as a session variable.

    I have to read the article again. It all starts to seem like a lost cause. We don't have that many clients, say 200. Is there another approach say like using a vpn...or ??

    We want it convenient for the client to login but we do not need to provide an easy means for registration. In other words we can physically access the clients computer to set something up.
    I previously mentioned 'Security is always a compromise between performance.', I must include usability and deployment as other factors.
    Theres no problem using SWF for the client to access the server, however I would recommend using SSL to connect to the server; ensure you sign the cookie over SSL as secure and that the server ensures the connection as secure. Using a cookie as a token to authenticate clients, and providing it's clearly thought out, can be secure enough.

    Different scenarios offer different solutions, especially when security and interoperability are concerned. So when you refer to clients, are these partners or customers? As you mention you have access to there computers? If these are partners, I would recommend deploying a certificate, which you can use to verify the partner as a user, and ensure that they enter a form of credential to verify the current user.

    Off Topic:


    I would give you a demonstration of the above, although I cannot find the example. From what I remember it was named something like CIRCB and was published from a university,, if I remember correctly. Hopefully someone can find it again.

    Lately, i've found Google pretty useless, taking me time to search for topics of interest, am I the only one being flooded with poor information, when searching for sites or specifics?

  23. #23
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...never trust the client. Do not cache username/passwords or any private data on the client.


    Doesn't matter what shape or form the data is, never ever trust it

    Specially nowadays, security should be the number one concern for the Internet, IMO above anything else.

  24. #24
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Miami
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes I agree that security is very important someone with motive might instigate an attack. In such a case the damage would be minimal but the loss of confidence from the client is what we worry about.


    The clients (Banks,Hmo's, etc) are not partners but we have to work together so a high level trust and cooperation is needed.

    Using a certificate assigned to clients sounds like something I would like to investigate and yes we would log them in using SSL. Maybe that will be enough as you say. If anyone knows more about this approach please comment.

    Thanks.

    ....right on about the google thing.

  25. #25
    SitePoint Zealot
    Join Date
    Dec 2003
    Location
    with my kids
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    like everything else on this forum, i think the security paranoia is a little overblown. has anyone here ever suffered from their data being sniffed on the wire and hacked? from their sessions being hijacked? ok, here comes everyone out of the woodwork.... but i'm just trying to get a sense of the problem.

    as developers, you probably use ftp alot: clear text. you login to this site and dozens others: clear text. you use basic authentication: little more than clear text. and i bet a lot of people use the same password for multiple sites.

    and what are you securing? the majority of the time it's an "article" site or something equally unspectacular.

    if you're handling something really sensitive like credit card data, then of course you should be using SSL and either not storing it on your server or encrypting it.

    as someone else said, once someone gets access to your server, game over.

    btw, of course you can also encrypt the session data. just yesterday i had a case where i needed to store the user/password of a non-sensitive site, without using a database. i think this is secure enough for the task:
    PHP Code:
    //this can be hard coded or come from the client like the 
    //javascript rand id that Yahoo uses
    $unique md5('Q42Taw7f0dd4');
    session_save_path('/some/dir/not/in/webroot');
    session_start();

    //these will be the session keys for the crypt key and the string data
    $k md5($unique);
    $s md5($k);

    //first access of page from a form
    if(isset($_POST['_user']) && isset($_POST['_pass']) && !isset($_SESSION[$k]) && !isset($_SESSION[$s])){
        
    $u trim(strip_tags($_POST['_user']));
      
    $p trim(strip_tags($_POST['_pass']));
        
      
    //the data as a string
      
    $data "$u~~$p";
        
      
    //the crypt key, stored in the unique session variable
      
    $_SESSION[$k] = md5(uniqid(mt_rand(), true));
        
      
    //encrypt the data
      
    $_SESSION[$s] = encrypt($data$_SESSION[$k]);
    /*
    ends up like this:
    187de669c5769b2779de7d38a2573684|s:32:b570689346a15f4a8dbcae4f00c80244;
     f2351ad23be1d12a3f895487381d419b|s:38:TYM[s\~3h5oιT
    */
    }

    //decrypt and retrieve the data
    if(isset($_SESSION[$s]) && isset($_SESSION[$k])){
        
    $data explode('~~',decrypt($_SESSION[$s], $_SESSION[$k]));
        
    $user $data[0];
        
    $pass $data[1];
    }
    else {
        echo 
    'Could not validate';
        exit;
    }

    /* From PHP user notes:
    robert at peakepro dot com
    03-Mar-2004 09:25
    */
    function encrypt($string,$key) {
       
    srand((double) microtime() * 1000000); //for sake of MCRYPT_RAND
      
    $td mcrypt_module_open('des''','cfb''');
      
    $key substr($key0mcrypt_enc_get_key_size($td));
      
    $iv_size mcrypt_enc_get_iv_size($td);
      
    $iv mcrypt_create_iv($iv_sizeMCRYPT_RAND);
      
    /* Initialize encryption handle */
       
    if (mcrypt_generic_init($td$key$iv) != -1) {

         
    /* Encrypt data */
         
    $c_t mcrypt_generic($td$string);
         
    mcrypt_generic_deinit($td);
         
    mcrypt_module_close($td);
           
    $c_t $iv.$c_t;
           return 
    $c_t;
       } 
    //end if
    }

    function 
    decrypt($string,$key) {
      
    /* Open module, and create IV */
      
    $td mcrypt_module_open('des''','cfb''');
      
    $key substr($key0mcrypt_enc_get_key_size($td));
      
    $iv_size mcrypt_enc_get_iv_size($td);
      
    $iv substr($string,0,$iv_size);
      
    $string substr($string,$iv_size);
      
    /* Initialize encryption handle */
       
    if (mcrypt_generic_init($td$key$iv) != -1) {

         
    /* Encrypt data */
         
    $c_t mdecrypt_generic($td$string);
         
    mcrypt_generic_deinit($td);
         
    mcrypt_module_close($td);
           return 
    $c_t;
       } 
    //end if
    }

    //etc..... 


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •