0

I am building a login system for my website, however I have always used the $_SESSION variable before for remembering people logged in, but this time they need to be remembered via cookies. The cookie will store their username and security code which I will also store in a database allowing me to confirm that they are the correct user. I have seen various approaches to this, however I would like to generate a completely secure string.

Thomas Denney
  • 1,578
  • 2
  • 15
  • 25
  • What does secure mean to you? What if wrong with your current approach? Saving a hashed value as key seems fine to me. – Michael-O Jul 31 '11 at 13:46
  • If you're worried about someone cracking your DB and making off with all the passwords, the way to do it is: 1. generate a salt (random string) for each user; 2. hash the salt + password multiple times (enough to take a significant fraction of a second). Unfortunately, what you're really worried about is someone eavesdropping and taking the identifying string. For that you need TLS. –  Jul 31 '11 at 13:49
  • I am already using MD5 for encryption of the passwords, however I do not want the encrypted version (of the password) visible in the cookie. Would it be possible to generate a short (6 character) random string in PHP, MD5 it, and then use that in the cookie instead? – Thomas Denney Jul 31 '11 at 13:52
  • BTW, this is very good read -> http://programmers.stackexchange.com/questions/51403/what-should-web-programmers-know-about-cryptography – Kumar Jul 31 '11 at 14:16

4 Answers4

4

$_SESSION already uses cookies by default, so you don't have to change anything. Just make sure the use_cookies and use_only_cookies configuration options are set to on.

phihag
  • 278,196
  • 72
  • 453
  • 469
0

I use the ASCII code with the function chr, from the character 33 to 126.

The function is like this:

$seed = "";
for ($i = 1; $i <= 20; $i++) {
    $seed .= chr( mt_rand(33,126) );
}
return md5($seed);
Rui Seixas Monteiro
  • 679
  • 5
  • 4
0

You could make a Cryptographically Secure Random String as suggested here

Here you generate a 32charater long string contaning (A-Z) & (0-9)

$token = bin2hex(openssl_random_pseudo_bytes(16));

# or in php7
$token = bin2hex(random_bytes(16));
ii iml0sto1
  • 1,654
  • 19
  • 37
0

A secret is usually a random number, which you can compute its md5 and put it inside a cookie, this is how I do it for one of my applications ($salt is a unique large arbitrary string): 

$rnd = mt_rand( 0, 0x7fffffff ) ^ crc32( $salt ) ^ crc32( microtime() );

$secret = md5( $rnd );

if you want to make it even more secure everytime you make a $rnd save it somewhere (in DB perhaps) and shift your next $rnd by its value and save that next $rnd in the DB...

nobody
  • 10,599
  • 4
  • 26
  • 43
  • Unmodified Mersenne-Twister is [not cryptographically secure](http://en.wikipedia.org/wiki/Pseudorandom_number_generator#Mersenne_Twister); and therefore shouldn't be used for cryptographic applications such as session ID generation. Also, `getMicroTime` should be implemented with `return microtime(true);`. Also, MD5 is [severely compromised](http://en.wikipedia.org/wiki/MD5#Security). Luckily, all these problems are largely theoretical; your algorithm will be safe against all but the most resourceful attackers (in 2011). – phihag Jul 31 '11 at 14:13
  • you're right my getMicrotime() is too much for this application I just copied it from my existing code. I edited and removed it. BTW I couldn't get from the link why my code is not secure specially if you use the old $rnd to shift the new $rnd. – nobody Jul 31 '11 at 14:20
  • `mt_rand`'s next output can in theory be predicted after seeing enough outputs. Since all other sources of randomness are in theory easy to guess, this makes the whole algorithm insecure in theory. – phihag Jul 31 '11 at 14:31
  • MD5 being compromised doesn't make this code insecure, if an attacker can hack into $secret what he gets to is $rnd which is of no use to him. Also shifting the value by $salt and microtime() makes predicting mt_rand() result almost impossible. anyway I think this code is secure enough for most applications. – nobody Jul 31 '11 at 14:32
  • Calculating the inverse of an MD5 hash is indeed not feasible, but why would you use MD5 instead of SHA-2 in the first place? And yes, you're right, this code will resist any publicly known attacks as of 2011. – phihag Jul 31 '11 at 14:39
  • performance? sha-2 might be too much for this app. actually I didn't look at md5() as an added security measure here just used it to have a cute strange looking string instead of an integer :D – nobody Jul 31 '11 at 15:01