Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 355
  • Last Modified:

Password / Login Security

I often write code that allows a user to logon to a website and I usually do it pretty much the same way.

The user registers on a page with their userid and password and this gets sent to the server. The server encrypts this (MD5 etc.) and stores the encrypted userid and encrypted password on the database.

At the time of registration, they also supply an email and you send a link to that email address which if they click it then activates the account and all is well.

There is then a login form where they enter their userid and password and this is sent to the server and it encrypts the entered userid password and checks to see if a userid equal to that encrypted value of the entered userid exists on the database and it is an active userid and the encrypted value of the password entered matched the encrypted value stored on the table.

If all is OK then we create a pair of cookies on the users PC with the userid (encrypted) and the password encrypted. Every time a page is requested, the cookie is examined and checked again and we also use this to get access levels for that userid from the database to  check if they can see the requested page or data.

All seems well and it all seems to work pretty well.

What worries me is that you read all about people sniffing traffic and the data is sent in clear from the PC to the Server - it only being encrypted when received at the server. Is this best practice?

Are there other, better, more secure ways of doing this? I know we could use https and SSL - but is this necessary for most sites?

Does anyone have any suggestions for making fairly trivial sites more secure? What do you suggest if you are moving into e-commerce?

Which is the main reason for the question! I should say that I intend the bank site to do all the real work of taking the payment and just have that appear on my site.

Many thanks
0
highlawn
Asked:
highlawn
  • 4
  • 3
  • 3
  • +2
4 Solutions
 
Dave BaldwinFixer of ProblemsCommented:
It is normal to get an SSL/TLS certificate so you can have HTTPS encrypted communication between the browser and your server.
0
 
ahoffmannCommented:
> .. we create a pair of cookies on the users PC with the userid (encrypted) and the password encrypted.
I'd never use the username and/or password as session ID, even not encrypted
you better establish a session management in your application (or probably your server offers one) and use a anonymous session ID which then will be mapped to the logged in user account
this makes no difference in stealing/hijacking the active session, but due to the (hoefully) random anon session ID, hijacking is possibly only as long as the session is alive on the server, wheras the encrypted username/password can be used any time later and also beidecrypted locally
I'd always use SSL  when something needs to be protected, think about WLAN where sniffing is very simple
0
 
Ray PaseurCommented:
Agree with DaveBaldwin.  If you're going to handle financial data you need SSL.  It is getting very common these days, since client privacy is always a concern.  That is only the tip of the iceberg.  You will want to learn about "PCI compliance."

Agree with ahoffmann - do not store meaningful data in a cookie (do not store meaningful data in any other key, for that matter).  Instead store a pointer to information on the server.  This strategy will let you keep client information in a way that is convenient for the client and also fairly safe...

When the browser sends a cookie, look up the client record according to the cookie.  If the client information is OK and the PHP session is active, allow the client to continue to interact.  If the PHP session is not active, request the client password and step through login authentication.  Easy!
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Slick812Commented:
greetings highlawn, computer and internet server "useful-practical security" is a large subject, and even some of the better web sites get "Hacked" into, and have stories in the news papers about it. Your description of your security set up, seems like a common pattern, as storing the password in a unique offset (hashing is not encryption), although I would think that the user name is rarely "hidden" with a hash, since it is displayed on a web page anyway. Although "user name" is often used as a "seed" for a password hash.

You as ask -
"What worries me is that you read all about people sniffing traffic and the data is sent in clear". . There are considerations to think about, but using SSL gives you added security, but may or may not be a "useful-practical" addition to your security set up.
What you may consider, is a from of  "Authentication", instead of hashing the user name, have an algorithm that creates a sort of "random" block of at least 24 characters (32 to 64 length for better security) from byte values of zero to 255, use this string as your "Authentication Code", then store and use this Authentication Code, to verify that your transactions are a little more secure. . You might even read the first character of your password hash, and mix-up the Authentication Code in one of 16 to 32 different ways to further secure it.

You can look at this wiki page, it's about "message authentication code", which is a little different than what I was saying, but may give you some ideas about what to research and seek. -
http://en.wikipedia.org/wiki/Message_authentication_code
0
 
Ray PaseurCommented:
Afterthought... This shows how you can reduce the risk of cookie tampering.
<?php // RAY_cookie_safety.php
error_reporting(E_ALL);


// DEMONSTRATE HOW TO ENCODE INFORMATION IN A COOKIE
// TO REDUCE THE RISK OF COOKIE TAMPERING


// A DATA DELIMITER
$dlm = '|';

// YOUR OWN SECRET CODE
$secret_code = 'MY SECRET';

// A DATA STRING THAT WE WANT TO STORE (MIGHT BE A DB KEY)
$cookie_value = 'MARY HAD A LITTLE LAMB';

// ENCODE THE DATA STRING TOGETHER WITH OUR SECRET
$cookie_code = md5($cookie_value . $secret_code);

// CONSTRUCT THE COOKIE STRING WITH THE CLEAR TEXT AND THE CODED STRING
$safe_cookie_value = $cookie_value . $dlm . $cookie_code;

// SET THE COOKIE LIKE "MARY HAD A LITTLE LAMB|cf783c37f18d007d23483b11759ec181"
setcookie('safe_cookie', $safe_cookie_value);



// WHEN STORED, THE COOKIE WILL BE URL-ENCODED SO IT WILL LOOK SOMETHING LIKE THIS ON THE BROWSER
// MARY+HAD+A+LITTLE+LAMB%7Ccf783c37f18d007d23483b11759ec181
// IT WILL BE URL-DECODED BEFORE IT IS PRESENTED TO PHP



// HOW TO TEST THE COOKIE
if (isset($_COOKIE["safe_cookie"]))
{
    // BREAK THE COOKIE VALUE APART AT THE DELIMITER
    $array = explode($dlm, $_COOKIE["safe_cookie"]);

    // ENCODE THE DATA STRING TOGETHER WITH YOUR SECRET
    $cookie_test = md5($array[0] . $secret_code);

    // IF THE MD5 CODES DO NOT MATCH, THE COOKIE IS NO LONGER INTACT
    if ($cookie_test == $array[1])
    {
        echo "<br/>THE COOKIE {$_COOKIE["safe_cookie"]} IS INTACT";
    }
    else
    {
        echo "<br/>THE COOKIE {$_COOKIE["safe_cookie"]} IS CORRUPT";
    }
}
else
{
    die('COOKIE IS SET - REFRESH THE BROWSER WINDOW NOW');
}




// MUNG THE COOKIE TO DEMONSTRATE WHAT HAPPENS WITH A CORRUPT COOKIE
$_COOKIE["safe_cookie"] = str_replace('MARY', 'FRED', $_COOKIE["safe_cookie"]);

// HOW TO TEST THE COOKIE
if (isset($_COOKIE["safe_cookie"]))
{
    // BREAK THE COOKIE VALUE APART AT THE DELIMITER
    $array = explode($dlm, $_COOKIE["safe_cookie"]);

    // ENCODE THE DATA STRING TOGETHER WITH OUT SECRET
    $cookie_test = md5($array[0] . $secret_code);

    // IF THE MD5 CODES DO NOT MATCH, THE COOKIE IS NO LONGER INTACT
    if ($cookie_test == $array[1])
    {
        echo "<br/>THE COOKIE {$_COOKIE["safe_cookie"]} IS INTACT";
    }
    else
    {
        echo"<br/>THE COOKIE {$_COOKIE["safe_cookie"]} IS CORRUPT";
    }
}

Open in new window

0
 
highlawnAuthor Commented:
Many thanks for the input, it is greatly appreciated. So, to recap:

1. The use of SSL/TLS certificates and HTTPS is encouraged regardless of your site content.
2. Use of hashing is encourgaed, but use of hashed "real" data should be avoided
3. PCI Compliance - can I not leave that to the payment provider - if I use their "fuller" offerings?
4. Use  session_start and $_SESSION to store logins
5. Consider other authentication extensions as proffered by slick812
6. Extend cookie info to detect some tampering as proffered by Ray

It is always most helpful to get good and reasoned input and I am about to set up some "standard" routines for this subject that I will be able to include in multiple sites - so always good to get a fresh view on it.

Anything else?
0
 
Dave BaldwinFixer of ProblemsCommented:
PCI compliance is all about security and making sure that credit card and personal information is not leaked or stolen.  If you store credit card information, you are supposed to meet full PCI compliance to prevent it from being leaked or stolen.
0
 
highlawnAuthor Commented:
Thanks for that Dave. My intention was to go as far as creating the shopping cart and then passing control over to the payment provider who will deal with the entire payment process and then let me know if authorised or not where after I would move into dispatch mode.

I realise they charge more for that - but they then have the PCI issues and not me.
0
 
ahoffmannCommented:
> PCI compliance is all about security and making sure that credit card and personal information is not leaked or stolen.
LOL

in theory (PCI), theory and praxis are identical, in praxis (anonymous) they are not

*SCNR*, DaveBaldwin, no offence in mind as I know you just quoted PCI DSS

@highlawn
to improve session security, I'd add
  7. set secure and HTTPonly flag for cookie, restrict cookie path to your application
0
 
Ray PaseurCommented:
As long as we are at it, here are a few other considerations :-)

Have backup generators to protect against power fluctuations, mirror your data base at offsite locations, perform background security checks on your employees and contractors, never use a shared server, never allow a programmer to change a script on the production machine, use a service like http://www.truste.com/ and change your locks often!
0
 
highlawnAuthor Commented:
I'm going to close this now and thank all respondents for their contribution and insights. It has all been very helpful and will assist greatly.

I can see not other equitable option than to split the points amongst you all.

Kind Regards
0
 
Dave BaldwinFixer of ProblemsCommented:
@ahoffman, yes, but I'm certainly not going to 'recommend' some of the things that I know are being done.  I Always recommend trying to 'do it right'.
0
 
highlawnAuthor Commented:
All answers were most helpful and all contributed to the overall response to the question. The only reason all aren't included in the solution is to ensure that all respondents benefited equally from the points on offer.
0
 
ahoffmannCommented:
>  I Always recommend trying to 'do it right'.
That's it.
The sentence "... PCI ... making sure ..." made me laughing. PCI is not bad, its good, but in practice I see the "PCI checked certificates" where the auditor simply checkedPCI compliant 'cause "SCA done", but(s)he never checked the application or the SCA results.

@highlawn good luck with your project
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 3
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now