Passworded cookie

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Passworded cookie

Post by dbsights »

Sup folks. Just wondering what you think of my implementation of a secure cookie system. Ill place the logical steps below and would be very interested to know of any vulnerabilities or massive failures. Here is a link to the actual code for those interested: viewtopic.php?f=50&t=101595 (Also, this is my first time with PHP, so any comments on code/conventions would be nice) (halp).

There are initially two pieces of data. I will call them $cleartext and $ciphertext. $cleartext will be sent in the clear while $ciphertext will be encrypted and then sent. Before anything else takes place, the expiration date is added to the $cleartext and both of the variables are serialized. (Is there a better (smaller) way of doing this without losing all of the flexibility of serialize()?).

Now the serialized $cleartext is hashed using the sha256 algorithm and the HMAC method with a secret key kept by the server to create the $key. This provides a fairly strong key that is based on the expiration time as well as any other information the server is willing to send in the clear. Because the $key is affected by both changes in time as well as unique information (most likely usernames), keys will almost never be reused. This should help make the encrypted portion of the cookie very resilient to cryptanalysis. Also, the HMAC method of hashing provides a way of hashing a $key that is immune to collisions and cannot be generated by an attacker without knowledge of the secret key.

After the $key is generated, mcrypt is initialized and set up to use AES-256 in cfb. A initialization vector is then generated by seeding the MCRYPT_RAND function with the sha256 hash of the $key and the current time in microseconds. The $key was hashed again so that even if the attacker could somehow break the AES, he would still be unable to send messages due to the HMAC verification (later). Also, 8 bytes of random characters are created and prepended to the $ciphertext. I was concerned that an attacker having the IV and knowing that I was using serialize could guess the first few characters of plaintext and work out the key. Probably unfounded, but these random characters added to the beginning of the message should cause it to scramble sufficiently to remove that advantage. Once the data is encrypted with the hashed key, I prepend the IV.

Then the cleartext and the encrypted ciphertext are HMAC hashed (sha256) with the $key to create a hash that can be used to verify that the message has not been tampered with. Finally, the entire message is XOR'd with a simple repeating string of one character to obfuscate its meaning to the average user.

Decryption is done in reverse. As long as the server knows the secret key, the actual key can be generated easily. As far as I know, there is no faster way for an attacker to break the cookie than to brute force the secret key.

This cookie, while kind of large, can be used to securely store things on the user's system for a fairly long period of time. My thinking right now is to send cookies like so (below) to the user and check it once when they visit a site. Then I will issue a short term session cookie that they will send at all times. OFC, for a lot of sensitive data, this should be fine as it. Ex. contents of a shopping cart.

Ex. Standard login Cookie
$cleartext = username
$ciphertext = password, ip

Quick question: Is there a better way than IP address to verify that the user is still on the same computer as when the cookie was set. Right now cookie theft is what I see as the number one vulnerability and I'm trying to think of ways around it.

So yeah tell me what you think.

Thanks.


DBSights
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

What are you trying to protect against? Storing a password in a cookie is never the best option no matter how complex encryptions you have applied. I think your system is overkill and accomplishes nothing really. Just store a strong session identifier in the cookie rather than a complex encryption and a obfuscation of a password..
dbsights wrote:Is there a better way than IP address to verify that the user is still on the same computer
I am assuming "the same computer" refers to a household? If so, an IP address could imply the change of a computer. However, many proxies causes IP changes and ISPs cycle their IPs. My old ISP switched my IP once a day. For some people, this happens more often and even on every page load.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

My initial idea for this came from a secure shopping cart application. I wanted something that would allow me to store state so I could reduce the frequency of database lookups but still provide security for the user. IE. so no one could read their last purchases etc.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

dbsights wrote:My initial idea for this came from a secure shopping cart application. I wanted something that would allow me to store state so I could reduce the frequency of database lookups but still provide security for the user.
The security design of the application smells. I don't know who wrote it, but one should never store passwords or usernames in cookies. Not even when encrypted. I don't understand your point about database lookups. If you have a filesystem based sessions (like PHP's built-in session system), then you need no database queries except for the initial login procedure.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

Storing the password on the client is done so that login can be automated (client doesn't need to provide password). Also, PHP's built in sessions are no good for multiple servers being load balanced. The cookie is relatively high security and so it can persist on the user's computer for a long time. Less secure, short-term session cookies can be provided for the duration of a user's visit. They can be sent in the clear and will expire fast enough that it is not really a big security concern.


How would you do it? The idea is to build a secure login system with the requirements that:
1. The user has the option of not having to enter their username or password. (Similar to GMail; pre-authenticated).
2. Provides session functionality.

And how would you deal with people stealing cookies and replaying them to the site to gain access to an existing session?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

dbsights wrote:Storing the password on the client is done so that login can be automated (client doesn't need to provide password).
And you actually need this?
dbsights wrote:PHP's built in sessions are no good for multiple servers being load balanced.
You can A) build your own session system or B) use the session_set_save_handler() and Memcached together to achieve the effect.
dbsights wrote:The cookie is relatively high security and so it can persist on the user's computer for a long time.
Maybe it is "relatively high" or maybe it is not. If the cookie is stolen by an attacker, he has unlimited time to crack it. Besides, he can use the same cookie to authenticate himself without even knowing the password (basically a replay attack).
dbsights wrote:short-term session cookies can be provided for the duration of a user's visit. They can be sent in the clear and will expire fast enough that it is not really a big security concern.
Do note that almost always cookies are stolen when the user visits the corresponding website in which case the cookie would most likely exist and indeed be stolen.
dbsights wrote:How would you do it? The idea is to build a secure login system with the requirements that:
1. The user has the option of not having to enter their username or password. (Similar to GMail; pre-authenticated).
2. Provides session functionality.
I would build my own session system and probably just use Memcached to be able to serve it to all servers. I would then store the session identifiers in cookies instead of the usernames or the passwords.
dbsights wrote:And how would you deal with people stealing cookies and replaying them to the site to gain access to an existing session?
You can't stop those replay attacks completely. With passwords and usernames, these replay attacks exist forever. With sessions, they exist until the session has expired. With sessions, you can even regenerate the identifier whenever you want to make sure older stolen identifiers do not work. Also, with session identifiers, an intruder can only use the stolen session identifier he got - he cannot know the password/username combination.

Another thing is the strength of the password vs the strength of the session identifier. With session identifiers, you can decide how strong identifiers you like. Gmail, for instance, uses session identifiers that are 1092-bits strong (thats over 5.3 sexvigintillion^4 combinations - read: impossible to brute force), but in your case, the passwords barely provide any strength (usually between 20-30-bits). You could use complex encryptions to achieve the illusion of high strength, however, doing so implies that your code is never exposed and you would be completely relying on obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity), which is not a good thing either.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

dbsights wrote:
How would you do it? The idea is to build a secure login system with the requirements that:
1. The user has the option of not having to enter their username or password. (Similar to GMail; pre-authenticated).
2. Provides session functionality.

I would build my own session system and probably just use Memcached to be able to serve it to all servers. I would then store the session identifiers in cookies instead of the usernames or the passwords.
The goal of this system was to satisfy condition #1. Logging in with a session identifier provides no security benefit over logging in with user/pass provided that information is secure. And the password would not be plaintext... Likely I will encode it w/ bcrypt and just save the encrypted form. Even with the overhead of decrypting the cookie, there will still be savings in not having to recompute the password using the much more expensive blowfish alg. Also, this form of cookie allows much more flexibility as it can also store user's browsing habits, etc. without their knowledge.
dbsights wrote:
The cookie is relatively high security and so it can persist on the user's computer for a long time.

Maybe it is "relatively high" or maybe it is not. If the cookie is stolen by an attacker, he has unlimited time to crack it. Besides, he can use the same cookie to authenticate himself without even knowing the password (basically a replay attack).
Perhaps I misled you as to the security of the cookie. It uses 256-bit AES (CFB) with a very complex and impossible to derive key as well as a random initialization vector and salted data. Also, the keys are never reused. While its true that an attacker downloading the cookie would have unlimited access to it, the simple fact is the attacker would die before he cracks the encryption. A replay attack is a completely different matter and has nothing to do with how the cookie is structured. As far as I can tell, everything is vulnerable to it; it is something that I would be very interested in finding a way to fix. I was considering saving IPs in the secure part of the cookie. But as you pointed out, people's IP change frequently. It would not work.
Another thing is the strength of the password vs the strength of the session identifier. With session identifiers, you can decide how strong identifiers you like. Gmail, for instance, uses session identifiers that are 1092-bits strong (thats over 5.3 sexvigintillion^4 combinations - read: impossible to brute force), but in your case, the passwords barely provide any strength (usually between 20-30-bits). You could use complex encryptions to achieve the illusion of high strength, however, doing so implies that your code is never exposed and you would be completely relying on obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity), which is not a good thing either.
See, thats just not true. Wikipedia links aside, you fundamentally misunderstood security through obscurity. I am using proven algorithms and indeed have released the entire system for your review. If you can find a faster way of cracking the cookie than guessing the secret key, that is something that I would really want to know. As for passwords vs. session identifiers, they are completely different and don't lend themselves to comparison. In order to use a session ID, you must provide a password. Session IDs are longer to avoid collisions and because it is harder to track incorrect session request while serial password-guessers can be quickly identified. As for GMail. you right that is a lot of data. Are you certain that its all just a session ID or is there encrypted data being passed in there.
You can't stop those replay attacks completely. With passwords and usernames, these replay attacks exist forever. With sessions, they exist until the session has expired. With sessions, you can even regenerate the identifier whenever you want to make sure older stolen identifiers do not work. Also, with session identifiers, an intruder can only use the stolen session identifier he got - he cannot know the password/username combination.
This is a good point. I am always very concerned about replay attacks and unless I find a way to limit them, this cookie cannot be used to store login information. Nonetheless, I think it will still be valuable as an encrypted store of data on the client.

So the real question is: what to do about replay attacks....? Ideas?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

There is a term called Session Hijacking. That is what you are asking for. The protect against it, one uses a secure session system with strong session identifiers and uses HTTPS. That is the best way to stop Session Hijacking. It even works seamlessly on shared IP addresses.
dbsights wrote:Logging in with a session identifier provides no security benefit over logging in with user/pass provided that information is secure.
Wrong. I already gave you good reasons.
dbsights wrote:And the password would not be plaintext...
Yes, I noticed. That's a bit overkill. All you need is a strong key and a strong algorithm.
dbsights wrote:A replay attack is a completely different matter and has nothing to do with how the cookie is structured.
We are actually talking about Session Hijacking, but in your case it's more of a replay attack, because it can happen repetitiously without any expiration. Expirating session identifiers greatly minimize the attack surface area, which is a very important security principle. (http://www.google.fi/search?hl=en&q=min ... tnG=Search)
dbsights wrote:I was considering saving IPs in the secure part of the cookie. But as you pointed out, people's IP change frequently.
Tieing IPs should never be strict or your users start to have problems. When it comes to Session Hijacking, one must ultimately use some sort of transport layer security mechanism (that provides a secure end-to-end transmission) to allow a secure session system. Strong session identifiers combined with transport layer security is a key to success.
dbsights wrote:As for passwords vs. session identifiers, they are completely different and don't lend themselves to comparison.
Exactly my point. You are using passwords as session identifiers. While there are no direct vulnerabilities in your approach (actually I haven't looked into your code other than a quick look), I cannot ever suggest anyone to replace session identifiers with passwords (not even if you encrypt them).
dbsights wrote:In order to use a session ID, you must provide a password.
Yes. And that is not acceptable to you?
dbsights wrote:Session IDs are longer to avoid collisions and because it is harder to track incorrect session request
No. Session identifiers are (or at least should be) strong due to security requirements. Collisions are almost never a problem. What comes to tracking of an incorrect session, the same thing happens with your password system. You need that one query to a database (or a file).
dbsights wrote:while serial password-guessers can be quickly identified.
Actually I bet your approach would be just the opposite - slower. You need to store the passwords (and usernames) somewhere. Whether it is a file or a database entry, you need to make a query whenever you receive this secured cookie. The same thing happens with session identifiers. The only difference being the fact that you need to apply an encryption process in your situation.
dbsights wrote:As for GMail. Are you certain that its all just a session ID or is there encrypted data being passed in there.
It is (pseudo) random data that is encoded into a usable session identifier.
dbsights wrote:The goal of this system was to satisfy condition #1
So, you absolutely require an automatic authentication? If so, I can only recommend some sort of client certificates, because other options are more or less flawed.

Replay attacks do not exist in case of session identifiers. That's how you prevent those. As what comes to Session Hijacking, that is a lot larger subject that I am happy to discuss.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

Actually I bet your approach would be just the opposite - slower. You need to store the passwords (and usernames) somewhere. Whether it is a file or a database entry, you need to make a query whenever you receive this secured cookie. The same thing happens with session identifiers. The only difference being the fact that you need to apply an encryption process in your situation.
Given that all the data is unique (and a hash is computed), I could use the entire cookie as a session identifier, authenticating it the first time and then using its fingerprint each time after. The downside to this is a larger cookie being sent, however as an upside the cookie is much more flexible.
dbsights wrote:
And the password would not be plaintext...

Yes, I noticed. That's a bit overkill. All you need is a strong key and a strong algorithm.
Actually, this is a performance deal. Since the password is stored in the database in an encrypted form, one that takes a good deal of time to compute, it is much faster to store the encrypted password and do a direct match than to reencrypt it. The extra security is just gravy. Besides, the cookie was designed to be flexible, nothing is hard-coded....
We are actually talking about Session Hijacking, but in your case it's more of a replay attack, because it can happen repetitiously without any expiration. Expirating session identifiers greatly minimize the attack surface area, which is a very important security principle. (http://www.google.fi/search?hl=en&q=min ... tnG=Search)
...except an expiry time. My intention was never for these cookies to last forever, but a long enough time to allow something like Amazon's one click shopping.

Well, this has degenerated into us quoting each other. So, to sum the conversation:
Sessions are not secure. Short duration minimizes risk, but there is no way to reliably prevent 'session hijacking'.
The cookie as I submitted it is much easier to hijack then standard sessions because of its longer lifetime.
Larger session identifiers increase the security of the session by making it much harder for an attacking to guess a valid session.
Larger cookie being sent over the wire = slower loading for user.

So yeah, this is definitely not an optimal situation, but it is my first piece of code, so that alright. I actually would really appreciate it if you could look over my code and give some critique. You seem to know a lot about php :). Thx for the points, I am sure they will help me improve my login system.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

dbsights wrote:My intention was never for these cookies to last forever, but a long enough time to allow something like Amazon's one click shopping.
Maybe your intention, but intruders do not work the way you want them to. Once the cookie is stolen, it lasts forever (they won't "destroy" it).
dbsights wrote:Sessions are not secure.
They are as secure as you build them to be..
dbsights wrote:The cookie as I submitted it is much easier to hijack then standard sessions because of its longer lifetime.
Your encrypted password in the cookie has a lower strength, too.
dbsights wrote:Larger cookie being sent over the wire = slower loading for user.
Theoretically.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

FFS
dbsights wrote:
My intention was never for these cookies to last forever, but a long enough time to allow something like Amazon's one click shopping.

Maybe your intention, but intruders do not work the way you want them to. Once the cookie is stolen, it lasts forever (they won't "destroy" it).
As I said before, the cookies contain an expiry time - in a tamper-proof format. Once this time has past the cookie is ignored, no matter how many times the attacker sends it. Seriously, look over the code.
dbsights wrote:
Sessions are not secure.

They are as secure as you build them to be..
Take it in context. Quoting a small portion and then, instead of giving insightful or useful comments, spouting off some vaguely elitist, ephemeral <span style='color:blue' title='I&#39;m naughty, are you naughty?'>smurf</span> just makes me angry. Session hijacking, by your own admission is a problem. You propose TLS and strong identifiers. However that doesn't prevent someone with access to the computer, or using a cross-site scripting attack from getting the cookie. It is a problem.
dbsights wrote:
The cookie as I submitted it is much easier to hijack then standard sessions because of its longer lifetime.

Your encrypted password in the cookie has a lower strength, too.
No it doesn't. I don't think you understand this concept, but encryption is very, very strong. It will not be broken, by anyone, in the foreseeable future. Not only that, but the password, should I choose to store it in the cookie, would have additional encryption performed on it for the aforementioned reasons. I really don't know why you could possibly think that your session identifier is stronger than an encryption that will likely take longer than the solar system will exist, to break.
dbsights wrote:
Larger cookie being sent over the wire = slower loading for user.

Theoretically.
The internet works on a request/response model. Since cookies are sent by the browser every request, a larger cookie will result in a longer loading time for the user. This is exacerbated by the fact that most users have a much lower upload speed than their download speed. I didn't say it would be significant, but it is most definitely there; nothing theoretical about it.


Ok. Lets talk about session hijacking. I understand you advocate TLS and a strong identifier. Why is it important that the identifier be strong, and what would you consider a good way to generate a strong identifier. Also, how would you deal with XSS attacks.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

Don't get nasty. Grab a beer.
dbsights wrote:As I said before, the cookies contain an expiry time - in a tamper-proof format. Once this time has past the cookie is ignored, no matter how many times the attacker sends it.
This means they have to reauthenticate themselves, which is not what you wanted. :crazy:
dbsights wrote:However that doesn't prevent someone with access to the computer,
Which has nothing to do with Session Hijacking. Really. There has to be something the user provides in order for him to authenticate himself. Whatever it is, by the use of it - an attacker can also authenticate himself, but I would not consider that Session Hijacking. If I leave my car keys on the table and you took them (and my car) - would you be hijacking in this case? No, I would not use that term, but maybe it is just me, I don't know.
dbsights wrote:I don't think you understand this concept, but encryption is very, very strong. It will not be broken, by anyone, in the foreseeable future.
Thanks for caring, but I have spent several months on analyzing the specific algorithm you are currently using (I actually remember the first five values of the forward S-box from the top of my head, 63 7C 77 7B F2). The thing is, I never said the encryption is inherently weak, I said the value you use for authentication is weak.
dbsights wrote:I really don't know why you could possibly think that your session identifier is stronger than an encryption that will likely take longer than the solar system will exist, to break.
It's not about the strength of the encryption. It's not about how easy it is to break it. In fact, that does not matter. It's all about the amount of combinations your encrypted password may construct.

Here's a simple demonstration:

Code: Select all

password: weak
after encryption: 0x54 0x29 x075 x066
Even if our encryption is strong here, that does not make the authentication value strong. The only thing that matters when someone wants to get in your system is to provide a valid value. He does not need to know anything about the inner workings. The only thing that matters is the amount of entropy (or strength) your authentication value has.

I created 1 MB of data with your class. My analysis of the data with Chi-Square test was:
Distribution: 25818.13
Random exceeding: 0%
Which indicates that the entropy or the strength of the value is poor.

Code: Select all

<?php
 
/**
 * Chi-square calculator in PHP.
 *
 * @author Kai Sellgren
 * @copyright Copyright (C) Kai Sellgren 2008
 * @license http://www.opensource.org/licenses/lgpl-license.php Lesser GNU Public License
 */
 
header('content-type: text/plain');
 
$file = 'a.txt';
$handle = fopen($file,'rb');
$data = fread($handle,1024*1024+1);
fclose($handle);
 
// Calculate char counts
$ccount = array();
for ($a = 0,$b = strlen($data);$a < $b;$a++)
{
 if (isset($ccount[ord($data[$a])]))
  $ccount[ord($data[$a])]++;
 else
  $ccount[ord($data[$a])] = 1;
}
 
$expc = strlen($data)/256;
$chisq = 0;
for ($i = 0; $i < 256; $i++)
{
 $a = $ccount[$i] - $expc;
 $chisq += ($a * $a) / $expc;
}
 
define('Z_MAX',6.0);
function poz($z)
{
 if ($z == 0.0)
  $x = 0.0;
 else
 {
  $y = 0.5 * abs($z);
  if ($y >= (Z_MAX * 0.5))
   $x = 1.0;
  else if ($y < 1.0)
  {
   $w = $y * $y;
   $x = ((((((((0.000124818987 * $w
               -0.001075204047) * $w +0.005198775019) * $w
               -0.019198292004) * $w +0.059054035642) * $w
               -0.151968751364) * $w +0.319152932694) * $w
               -0.531923007300) * $w +0.797884560593) * $y * 2.0;
  }
  else
  {
   $y -= 2.0;
   $x = (((((((((((((-0.000045255659 * $y
                     +0.000152529290) * $y -0.000019538132) * $y
                     -0.000676904986) * $y +0.001390604284) * $y
                     -0.000794620820) * $y -0.002034254874) * $y
                     +0.006549791214) * $y -0.010557625006) * $y
                     +0.011630447319) * $y -0.009279453341) * $y
                     +0.005353579108) * $y -0.002141268741) * $y
                     +0.000535310849) * $y +0.999936657524;
  }
 }
 return ($z > 0.0 ? (($x + 1.0) * 0.5) : ((1.0 - $x) * 0.5));
}
 
define('LOG_SQRT_PI',0.5723649429247000870717135);
define('I_SQRT_PI',0.5641895835477562869480795);
define('BIGX',20.0);
 
function ex($x)
{
 return (($x < -BIGX) ? 0.0 : exp($x));
}
 
function pochisq($ax,$df)
{
 $x = $ax;
 if ($x <= 0.0 || $df < 1)
  return 1.0;
 $a = 0.5 * $x;
 $even = (2 * (int) ($df / 2)) == $df;
 if ($df > 1)
  $y = ex(-$a);
 $s = ($even ? $y : (2.0 * poz(-sqrt($x))));
 if ($df > 2)
 {
  $x = 0.5 * ($df - 1.0);
  $z = ($even ? 1.0 : 0.5);
  if ($a > BIGX)
  {
   $e = ($even ? 0.0 : LOG_SQRT_PI);
   $c = log($a);
   while ($z <= $x)
   {
    $e = log($z) + $e;
    $s += ex($c * $z - $a - $e);
    $z += 1.0;
   }
   return ($s);
  }
  else
  {
   $e = ($even ? 1.0 : (I_SQRT_PI / sqrt($a)));
   $c = 0.0;
   while ($z <= $x)
   {
    $e = $e * ($a / $z);
    $c = $c + $e;
    $z += 1.0;
   }
   return ($c * $y + $s);
  }
 }
 else
  return $s;
}

echo "Distribution: ".round($chisq,2)."\nRandom exceeding: ".pochisq(round($chisq,2),255)*100 . "%";
 
?>
Whether the low strength really matters much that we can all decide ourselves, but we are talking about security here. And in terms of security, using a stronger identifier is better as long as it's practical.
dbsights wrote:Why is it important that the identifier be strong,
Because with this single value anyone can get in. To make the decision between low and high strength identifiers easier, it cost virtually nothing to have strong identifiers.
dbsights wrote:and what would you consider a good way to generate a strong identifier.
Personally, I use the pseudo random /dev/urandom, which is seeded with the "true" RNG /dev/random, to generate 256-bits of pseudo random data. After that, I simply encode it with base 64 as it the largest base within the power of 2 that contains printable characters. Since the pseudo random number generator is always seeded with a "true" RNG, I can safely use a lossless encoding due to it not leaking any state of the random function unlike in the case of the built-in (mt_)rand() functions.
dbsights wrote:Also, how would you deal with XSS attacks.
Oh well, that is a large topic. Generally speaking, I take care of I/O encoding/escaping. That's probably the single most important fact.

I still don't understand why do you need to store passwords and usernames rather than session identifiers. You do know that you can make the session cookie to last long? If someone has to provide his password once a week or once a month, is that not acceptable?

Maybe you could elaborate what are you trying to achieve? What is the purpose of storing the passwords in cookies and what are your intentions.

Anyway, I think I have made myself clear here. I won't approve an approach of storing usernames or passwords in cookies no matter how great excuses people throw at me. It's not my project, it's yours, so, you make the call. If you want to do it the way you want, then you can do it.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Passworded cookie

Post by kaisellgren »

Now that I have slept, let me tell you my what I see.

You are introducing a mechanism that authenticates a user automatically. This mechanism has two keys (the username and the password). In addition to that, this mechanism has an expiry time.

Is there a name for this kind of system? Yup, it's called a Session. I do not understand why you want to reinvent the wheel and create your overly complex encryption, hashing and obfuscation system. It's all just more work and you do not really achieve anything.

If you wanted to try and play around with encryptions and own session mechanisms, sure, why not? But implementing it is a No. Or maybe for testing purposes you chould try to implement your approach as well as the original Session based approach with identifiers and see what your first approach has that the original session system approach does not (which is nothing really..).

Your original question was:
dbsights wrote:The idea is to build a secure login system with the requirements that:
1. The user has the option of not having to enter their username or password. (Similar to GMail; pre-authenticated).
2. Provides session functionality.
Which is exactly what the standard session system based approach has. They last as long as you want them to. That is exactly what Gmail is doing. I haven't looked into the expiry time they use, but today I had to login, and now I will probably stay logged in for a good amount of time.

It can be fun to create own session systems, but do not expect anyone to embrace your approaches even if they are not directly vulnerable to anything. ;)
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Passworded cookie

Post by onion2k »

dbsights wrote:Also, PHP's built in sessions are no good for multiple servers being load balanced.
Maybe this has been covered later in the thread (not read it all yet), but that's wrong. Most load balancing hardware and software can easily be set up to send the user to the same node for every request with some sort of client affinity algorithm. With that in place you can just use PHP's built-in session handler with no problems.
dbsights
Forum Newbie
Posts: 13
Joined: Thu Jun 11, 2009 6:44 pm

Re: Passworded cookie

Post by dbsights »

Hah, sorry about that then. That is some interesting chi, but I can't say I am surprised; the majority of the cookie data is just the cleartext and a hash based on the cleartext and ciphertext. What kind of setup did you use to get the 1 MB of data? I ask because the key is based entirely on time if no cleartext is provided, and so that might be the cause for the low randomness.

Also you said that the problem was the weakness of the password not the encryption. How would you exploit this fact? As far as I know, there is no way to easily decrypt if the source is weak and I fail to see any other method of identifying the password without decryption. Although... Having the password just hanging out there, unreachable, could throw some hackzorz into a fit of nerd-rage and unintentionally cause many more attacks than there would normally be.

And yes, this is essentially a session. I was looking for a way of making data persist client side, and then got into making it tamperproof. Then I added some encryption. Before I knew it, I was making an authentication system...

As a side note. I am right now working on making a session system using what I heard from here. I know memcached is very robust, but how does it compare to APC (besides the obvious local vs distributed). I have heard that APC can have trouble storing large numbers of objects.
Post Reply